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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0023818
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformmajorhave not tried2013-05-14 14:012013-05-30 17:14
ReportershuehnerView Statuspublic 
Assigned Toalostale 
PriorityurgentResolutionfixedFixed in Version3.0MP24
StatusclosedFix in branchFixed in SCM revision329f2507a53f
ProjectionnoneETAnoneTarget Version3.0MP24
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned ToAugustoMauch
Web browser
ModulesCore
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
Summary

0023818: 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.
TagsPerformance
Attached Filesdiff file icon log_connection_creator_for_classic_pool.diff [^] (984 bytes) 2013-05-14 14:02 [Show Content]
diff file icon 2nd_prototype.diff [^] (551 bytes) 2013-05-14 14:02 [Show Content]

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 0023882 closedalostale 2 dangling DB connections after Tomcat start 

-  Notes
(0058743)
alostale (manager)
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 (developer)
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 (developer)
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 (administrator)
2013-05-30 17:13

 Code reviewed and verified in pi@1693de72b307

- Issue History
Date Modified Username Field Change
2013-05-14 14:01 shuehner New Issue
2013-05-14 14:01 shuehner Assigned To => AugustoMauch
2013-05-14 14:01 shuehner Modules => Core
2013-05-14 14:01 shuehner Triggers an Emergency Pack => No
2013-05-14 14:02 shuehner File Added: log_connection_creator_for_classic_pool.diff
2013-05-14 14:02 shuehner File Added: 2nd_prototype.diff
2013-05-14 14:07 shuehner Regression level => Production - Confirmed Stable
2013-05-14 14:07 shuehner Regression date => 2009-10-30
2013-05-14 14:07 shuehner Regression introduced by commit => https://code.openbravo.com/erp/stable/2.50/rev/30a3de89fd2a [^]
2013-05-14 16:34 alostale Assigned To AugustoMauch => alostale
2013-05-15 10:09 egoitz Issue Monitored: egoitz
2013-05-22 11:14 alostale Note Added: 0058743
2013-05-22 11:15 alostale Review Assigned To => AugustoMauch
2013-05-22 11:27 hgbot Checkin
2013-05-22 11:27 hgbot Note Added: 0058745
2013-05-22 11:27 hgbot Status new => resolved
2013-05-22 11:27 hgbot Resolution open => fixed
2013-05-22 11:27 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/329f2507a53f189e8c6f035917df45cb695079c3 [^]
2013-05-22 11:43 alostale Relationship added related to 0023882
2013-05-23 01:34 hudsonbot Checkin
2013-05-23 01:34 hudsonbot Note Added: 0058850
2013-05-24 15:02 alostale Tag Attached: Performance
2013-05-30 17:13 AugustoMauch Note Added: 0059078
2013-05-30 17:13 AugustoMauch Status resolved => closed
2013-05-30 17:14 AugustoMauch Fixed in Version => 3.0MP24

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker