Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0023818Openbravo ERPA. Platformpublic2013-05-14 14:012013-05-30 17:14
Reportershuehner 
Assigned Toalostale 
PriorityurgentSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target Version3.0MP24Fixed in Version3.0MP24 
Merge Request Status
Review Assigned ToAugustoMauch
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression levelProduction - Confirmed Stable
Regression date2009-10-30
Regression introduced in release
Regression introduced by commithttps://code.openbravo.com/erp/stable/2.50/rev/30a3de89fd2a [^]
Triggers an Emergency PackNo
Summary0023818: Background scheduler takes 10 connections to database and never releases those
DescriptionThe background scheduler is starting 10 threads by default and each of those is keeping open one db-connection all the time without releasing it ever.

That way 10 connections more then necessary are kept open to the database leading to increases memory consumption for the system.

Technically this is a regression introduced in the AuditTrail project sometime during the 2.50 cycle.
Steps To ReproduceStart with normal pi with the background processes scheduled.
Apply debugging patch attached to this issue (it will show stack of code forcing the classic connection pool to increase its size)
start tomcat
Monitor number of connection to the database done by this tomcat.
Observe the number increasing over the first around 10min after tomcat start.
Using the debugging patch from above observe that those 10 extra connections are created by code running the quartz triggerFired callback,

For testing try the 2nd prototype patch attached to this issue which is disabling an optimization added to the AuditTrail project. That optimization disabled closeConnection doing anything relying on some ThreadHandler to close the connection really on http-request-termination. However that code will never close the connection for the quartz case. That 2nd patch just kills that optimization to show the end-result which can be gained.

That 2nd patch is NOT intended to be applied anywhere outside of testing. It just demonstrates the goal of the fix.
Proposed SolutionImprove that SessionInfo class to exclude the quartz threads from the ThreadLocal tracking the session request.
Additional Information
TagsPerformance
Relationships
related to defect 0023882 closed alostale 2 dangling DB connections after Tomcat start 
Attached Filesdiff log_connection_creator_for_classic_pool.diff (984) 2013-05-14 14:02
https://issues.openbravo.com/file_download.php?file_id=6131&type=bug
diff 2nd_prototype.diff (551) 2013-05-14 14:02
https://issues.openbravo.com/file_download.php?file_id=6132&type=bug
Issue History
Date ModifiedUsernameFieldChange
2013-05-14 14:01shuehnerNew Issue
2013-05-14 14:01shuehnerAssigned To => AugustoMauch
2013-05-14 14:01shuehnerModules => Core
2013-05-14 14:01shuehnerTriggers an Emergency Pack => No
2013-05-14 14:02shuehnerFile Added: log_connection_creator_for_classic_pool.diff
2013-05-14 14:02shuehnerFile Added: 2nd_prototype.diff
2013-05-14 14:07shuehnerRegression level => Production - Confirmed Stable
2013-05-14 14:07shuehnerRegression date => 2009-10-30
2013-05-14 14:07shuehnerRegression introduced by commit => https://code.openbravo.com/erp/stable/2.50/rev/30a3de89fd2a [^]
2013-05-14 16:34alostaleAssigned ToAugustoMauch => alostale
2013-05-15 10:09egoitzIssue Monitored: egoitz
2013-05-22 11:14alostaleNote Added: 0058743
2013-05-22 11:15alostaleReview Assigned To => AugustoMauch
2013-05-22 11:27hgbotCheckin
2013-05-22 11:27hgbotNote Added: 0058745
2013-05-22 11:27hgbotStatusnew => resolved
2013-05-22 11:27hgbotResolutionopen => fixed
2013-05-22 11:27hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/329f2507a53f189e8c6f035917df45cb695079c3 [^]
2013-05-22 11:43alostaleRelationship addedrelated to 0023882
2013-05-23 01:34hudsonbotCheckin
2013-05-23 01:34hudsonbotNote Added: 0058850
2013-05-24 15:02alostaleTag Attached: Performance
2013-05-30 17:13AugustoMauchNote Added: 0059078
2013-05-30 17:13AugustoMauchStatusresolved => closed
2013-05-30 17:14AugustoMauchFixed in Version => 3.0MP24

Notes
(0058743)
alostale   
2013-05-22 11:14   
Executed tests to verify this fix:

* Using pg9x (just to have more info in pg_stat_activity)
* Create a process that does some DB change
* Schedule this process to be executed every 5 secs
* Close all browser tabs to Openbravo
* Restart Tomcat

Verify that:

* After starting Tomcat, 3 connections are opened (select * from pg_stat_activity)
* When first process is executed 2 new connections appear
* When 2nd process is executed it doesn't take extra connections but reuses the ones created for previous one <- Previously each new execution up to 10, created a new connection
* Modifications done by process are persisted in DB
(0058745)
hgbot   
2013-05-22 11:27   
Repository: erp/devel/pi
Changeset: 329f2507a53f189e8c6f035917df45cb695079c3
Author: Asier Lostalé <asier.lostale <at> openbravo.com>
Date: Wed May 22 11:25:59 2013 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/329f2507a53f189e8c6f035917df45cb695079c3 [^]

fixed bug 23818: background scheduler takes db connections which are no released

ProcessMonitor now returns connections to pool after using them

---
M src/org/openbravo/scheduling/ProcessMonitor.java
---
(0058850)
hudsonbot   
2013-05-23 01:34   
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/97c7f6256af7 [^]

Maturity status: Test
(0059078)
AugustoMauch   
2013-05-30 17:13   
Code reviewed and verified in pi@1693de72b307