Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0025511
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 09. Financial managementmajorhave not tried2014-01-20 09:502014-05-27 17:19
ReportershuehnerView Statuspublic 
Assigned ToAtulOpenbravo 
PrioritynormalResolutionfixedFixed in Version
StatusclosedFix in branchFixed in SCM revision7b4ae1da74cb
ProjectionnoneETAnoneTarget Version3.0PR14Q2
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Todmiguelez
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0025511: Performance problems with 2 alertrule created by ModuleScript: Issue21640WrongMatchInvAccounting

DescriptionThis Modulescript creates 2 sql-based Alertrules whose execution is in many cases really slow (up to 20-30 seconds).

Technically this modulescript is inserting 2 ad_alertrule with its sql and then immediately executes those sql's to insert the needed ad_alert entries directly.

But as the ad_alertrule do exist and contain the sql they will be executed forever over and over again during the normal background alert processing.

Based on the description of the issue the purpose of those alerts is to check for wrong data created by some old accounting bug and to advise the user if any is found.

This means that after the check has been ran it is not needed to be ran again over the same data.

Disabling the sql in the alertrule would achieve that, as then the check would only be ran once (first time the modulescript is ran).

However this would switch of the part of marking the alerts as done automatically after the user did do the re-posting of the affected documents.

That could be avoided by special casing this in the modulescript. Adding a check if there art any alerts creating by this alertrule and then re-checking only those documents forever again (until the ad_alerts are deleted or marked as solved).
Steps To Reproduce-
Proposed SolutionThe ad_alertrule table has a 'type' column which is normally set to 'D' (data-driven, aka sql-based) having the usual semantics.

However there is also a type 'E' (external) which does nothing as a rule but exists so that some custom code can do the ad_alert inserts.

Note: That this type 'E' in practice has never been used so needs to be tested first if it works fine.

Assuming it does:
- The ModuleScript should be changed to insert the ad_alertrule with type 'E'
- For that it needs to 'find' it rules based on name instead of sql as the alertrule will no longer contain the sql.
- Furthermore the existing ad_alertrule created by previous execution of this modulescript should be changed from type=D to type=E and have their sql removed.

Note: It is important to have the sql-column empty as the current AlertProcess.java code filters for that when processing alerts and is not using the type=D.

Note when the last part of the description should be implemented code for this needs to be added to the modulescript to:
- get alertrule by from name
- select ad_alert for this ad_alertrule_id having status not yet solved
- for those docuents only, recheck the consistency with the sql.

TagsPerformance
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to design defect 0026772 newjonalegriaesarte Should implement a feature to execute again alerts defined as type 'E' (external) 

-  Notes
(0063705)
AtulOpenbravo (developer)
2014-01-27 10:46

 Test Plan
- After applying the fix, for module script execution either do ant smartbuild -Dlocal=no or ant update.database
- Check that alert rule for wrong matched invoice posting if exists are set with blank SQL and type ='E'.
- If alert rule for wrong matched invoice posting does not exists then new alert rules created are set with blank SQL and type ='E'.
(0063706)
hgbot (developer)
2014-01-27 10:52

 Repository: erp/devel/pi
Changeset: 7b4ae1da74cb2c7a0e06c1fc28a8fba7d18edf4a
Author: Atul Gaware <atul.gaware <at> openbravo.com>
Date: Fri Jan 24 14:30:20 2014 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/7b4ae1da74cb2c7a0e06c1fc28a8fba7d18edf4a [^]

Fixes Issue 25511:WrongMatchInvAccounting modulescript alertrule performance

---
M src-util/modulescript/build/classes/org/openbravo/modulescript/Issue21640WrongMatchInvAccounting.class
M src-util/modulescript/build/classes/org/openbravo/modulescript/Issue21640WrongMatchInvAccountingData.class
M src-util/modulescript/src/org/openbravo/modulescript/Issue21640WrongMatchInvAccounting.java
M src-util/modulescript/src/org/openbravo/modulescript/Issue21640WrongMatchInvAccounting_data.xsql
---
(0063717)
dmiguelez (developer)
2014-01-27 12:40

 Code Review + Testing OK
(0064116)
hudsonbot (developer)
2014-02-12 18:29

 A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/d1a5bb862230 [^]
Maturity status: Test

- Issue History
Date Modified Username Field Change
2014-01-20 09:50 shuehner New Issue
2014-01-20 09:50 shuehner Assigned To => dmiguelez
2014-01-20 09:50 shuehner Modules => Core
2014-01-20 09:50 shuehner Triggers an Emergency Pack => No
2014-01-20 09:53 shuehner Tag Attached: Performance
2014-01-20 12:01 pramakrishnan Target Version => 3.0MP32
2014-01-21 09:34 AtulOpenbravo Assigned To dmiguelez => AtulOpenbravo
2014-01-27 10:39 AtulOpenbravo Status new => scheduled
2014-01-27 10:39 AtulOpenbravo fix_in_branch => pi
2014-01-27 10:46 AtulOpenbravo Note Added: 0063705
2014-01-27 10:47 AtulOpenbravo Review Assigned To => dmiguelez
2014-01-27 10:47 AtulOpenbravo fix_in_branch pi =>
2014-01-27 10:52 hgbot Checkin
2014-01-27 10:52 hgbot Note Added: 0063706
2014-01-27 10:52 hgbot Status scheduled => resolved
2014-01-27 10:52 hgbot Resolution open => fixed
2014-01-27 10:52 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/7b4ae1da74cb2c7a0e06c1fc28a8fba7d18edf4a [^]
2014-01-27 12:40 dmiguelez Note Added: 0063717
2014-01-27 12:40 dmiguelez Status resolved => closed
2014-02-12 18:29 hudsonbot Checkin
2014-02-12 18:29 hudsonbot Note Added: 0064116
2014-05-27 17:19 rafaroda Note Added: 0067484
2014-05-27 17:38 shuehner Note Deleted: 0067484
2014-06-03 16:30 maite Relationship added related to 0026772

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker