Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Openbravo ERP] 04. Warehouse managementmajoralways2015-03-03 18:302015-04-01 10:49
ReporterumartirenaView Statuspublic 
Assigned Toumartirena 
PriorityhighResolutionfixedFixed in Version3.0PR15Q2
StatusclosedFix in branchFixed in SCM revisiond80a1e60b2e0
ProjectionnoneETAnoneTarget Version3.0PR15Q2
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned ToSandrahuguet
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0029487: Performance Problems on Costing Background process

DescriptionRunning Costing Background process on an environment with a lot of transactions to be calculated (200.000), it consumes a lot of memory and cpu, and it does not finish.
Steps To ReproduceWe have an environment with a lot of transactions in which the problem is reproduced.

Launch Costing Background process.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
blocks defect 0029118 closedumartirena Performance Problems on Costing Background process 

-  Notes
hgbot (developer)
2015-04-01 10:48

Repository: erp/backports/3.0PR15Q2
Changeset: d80a1e60b2e0bd92285d10e026a81aa9e093a317
Author: Unai Martirena <unai.martirena <at>>
Date: Wed Mar 04 16:09:33 2015 +0100
URL: [^]

Fixes bug 29487: Performance improved in Costing Background process.

There are two methods in Costing Background process in which an ScrollableResult is built and iterated. 'setCalculatedTransactionsAsProcessed' and 'setCalculatedTransactionsAsProcessed'. This loops where causing Out of memory issues because they were not flushing and clearing session every little amount of iterations. Apart from this, the two ScrollableResults were leaving opened, which may cause lot of issues especially in Oracle.

Finally, these methods have been implemented in another way. Directly updating all the records on a single update in hql. In this way the performance is improved even adding flush and clear on the previously loops.

M src/org/openbravo/costing/
Sandrahuguet (developer)
2015-04-01 10:49

Code review + testing OK

- Issue History
Date Modified Username Field Change
2015-04-01 09:43 Sandrahuguet Type defect => backport
2015-04-01 09:43 Sandrahuguet Target Version => 3.0PR15Q2
2015-04-01 09:44 Sandrahuguet Tag Attached: Approved
2015-04-01 10:48 hgbot Checkin
2015-04-01 10:48 hgbot Note Added: 0076289
2015-04-01 10:48 hgbot Status scheduled => resolved
2015-04-01 10:48 hgbot Resolution open => fixed
2015-04-01 10:48 hgbot Fixed in SCM revision => [^]
2015-04-01 10:49 Sandrahuguet Review Assigned To => Sandrahuguet
2015-04-01 10:49 Sandrahuguet Note Added: 0076291
2015-04-01 10:49 Sandrahuguet Status resolved => closed
2015-04-01 10:49 Sandrahuguet Fixed in Version => 3.0PR15Q2

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker