Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0043440Openbravo ERPA. Platformpublic2020-03-05 19:162023-12-11 23:24
ReporterioritzCia 
Assigned ToioritzCia 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionout of date 
PlatformOS30OS VersionUbuntu 18.04
Product Version 
Target VersionFixed in Version 
Merge Request Status
Review Assigned Todmitry_mezentsev
OBNetwork customer
Web browserGoogle Chrome
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0043440: [Performance] With an certain code in evenhandlers it is possible to leave non reusable connections in the pool
DescriptionWith an certain code in evenhandlers it is possible to leave non reusable connections in the pool.

Code must be improved in the eventhandlers, but some changes are required in platform as well.
Steps To Reproduce- In tomcat conf in server.xml file un comment line:
        <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
               maxThreads="150" minSpareThreads="4"/>
  and put maxThreads="5"
- In an environment with retail apply the attached patch
- Log in the system with a user and go to User -> User roles and activate and deactivate some user roles
- Open, refresh and close windows
- Log out and log in with another user
- Do the same
- Wait more than two minutes
- Go to the database and execute 'select * from pg_stat_activity order by xact_start;'
- There are connections with state_change older than 2 minutes that the pool should have closed (because of the default db.pool.minEvictableIdleTimeMillis=120000 configuration in Openbravo.properties)
Proposed Solution
Additional Information
TagsPerformance
Relationships
Attached Filesdiff UserRoleEventHandler.diff (5,913) 2020-03-05 19:16
https://issues.openbravo.com/file_download.php?file_id=14142&type=bug
diff UserRoleEventHandlerv2.diff (5,958) 2020-03-13 10:57
https://issues.openbravo.com/file_download.php?file_id=14165&type=bug
Issue History
Date ModifiedUsernameFieldChange
2020-03-05 19:16ioritzCiaNew Issue
2020-03-05 19:16ioritzCiaAssigned To => platform
2020-03-05 19:16ioritzCiaFile Added: UserRoleEventHandler.diff
2020-03-05 19:16ioritzCiaWeb browser => Google Chrome
2020-03-05 19:16ioritzCiaModules => Core
2020-03-05 19:16ioritzCiaResolution time => 1584572400
2020-03-05 19:16ioritzCiaTriggers an Emergency Pack => No
2020-03-05 19:17ioritzCiaTag Attached: Performance
2020-03-05 19:22ioritzCiaWeb browserGoogle Chrome => Google Chrome
2020-03-05 19:22ioritzCiaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=20521#r20521
2020-03-13 10:57caristuFile Added: UserRoleEventHandlerv2.diff
2020-03-13 11:01caristuNote Added: 0118582
2020-03-13 11:01caristuAssigned Toplatform => ioritzCia
2020-03-13 11:01caristuStatusnew => feedback
2020-03-13 11:03caristuNote Edited: 0118582bug_revision_view_page.php?bugnote_id=0118582#r20556
2020-03-13 11:04caristuWeb browserGoogle Chrome => Google Chrome
2020-03-13 11:04caristuSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=20557#r20557
2023-12-11 23:24dmitry_mezentsevReview Assigned To => dmitry_mezentsev
2023-12-11 23:24dmitry_mezentsevNote Added: 0158061
2023-12-11 23:24dmitry_mezentsevStatusfeedback => closed
2023-12-11 23:24dmitry_mezentsevResolutionopen => out of date

Notes
(0118582)
caristu   
2020-03-13 11:01   
(edited on: 2020-03-13 11:03)
It seems that the problem of the connections not being evicted is because a bad management of the ThreadLocal variable used by the event handler. The ThreadLocal is currently keeping in memory the reference to the hibernate Transaction and it is never being cleanup once it is no longer needed. Somehow this is not allowing the pool to close the idle connections that it should close to reach the configured limit.

To confirm this, we have modified the provided event handler (UserRoleEventHandlerv2.diff) but we are forcing the cleanup of the ThreadLocal variable.

Put this issue in feedback status, waiting for confirmation that with this change the problem can't be reproduced.
(0158061)
dmitry_mezentsev   
2023-12-11 23:24   
Too long in feedback