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

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 04. Warehouse managementmajoralways2015-03-03 18:302015-05-07 22:16
ReporterumartirenaView Statuspublic 
Assigned Toumartirena 
PriorityhighResolutionfixedFixed in Version3.0PR15Q3
StatusclosedFix in branchFixed in SCM revision115dc3041496
ProjectionnoneETAnoneTarget Version
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

0029118: 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.
TagsApproved, Performance
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
depends on backport 00291883.0PR15Q1.3 closedumartirena Performance Problems on Costing Background process 
depends on backport 00294873.0PR15Q2 closedumartirena Performance Problems on Costing Background process 

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

Repository: erp/devel/pi
Changeset: 115dc304149663ee5e27d18077840054823b35ca
Author: Unai Martirena <unai.martirena <at>>
Date: Wed Mar 04 16:09:33 2015 +0100
URL: [^]

Fixes bug 29118: 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
hudsonbot (developer)
2015-05-07 22:16

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

Promotion changeset: [^]
Maturity status: Test

- Issue History
Date Modified Username Field Change
2015-03-03 18:30 umartirena New Issue
2015-03-03 18:30 umartirena Assigned To => Sandrahuguet
2015-03-03 18:30 umartirena Modules => Core
2015-03-03 18:30 umartirena Triggers an Emergency Pack => No
2015-03-03 18:30 umartirena Tag Attached: Performance
2015-03-03 18:31 umartirena Assigned To Sandrahuguet => umartirena
2015-03-09 09:21 umartirena Status new => scheduled
2015-03-09 20:02 dmitry_mezentsev Tag Attached: Approved
2015-04-01 09:43 Sandrahuguet Status scheduled => acknowledged
2015-04-01 09:43 Sandrahuguet Status acknowledged => scheduled
2015-04-01 10:48 hgbot Checkin
2015-04-01 10:48 hgbot Note Added: 0076290
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: 0076293
2015-04-01 10:49 Sandrahuguet Status resolved => closed
2015-04-01 10:49 Sandrahuguet Fixed in Version => 3.0PR15Q3
2015-05-07 22:16 hudsonbot Checkin
2015-05-07 22:16 hudsonbot Note Added: 0077107

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker