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

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformmajorhave not tried2018-02-13 11:262018-02-22 18:19
ReporterAugustoMauchView Statuspublic 
Assigned Toalostale 
PrioritynormalResolutionfixedFixed in Version3.0PR18Q2
StatusclosedFix in branchFixed in SCM revisiond126554d216b
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned ToAugustoMauch
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0037899: Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed

DescriptionPOS session do not count for the maximum number of concurrent users, ERP sessions do count.

There is a problem when opening the back office from the POS that can lead to an ERP session that is not closed, even when there is no activity in the ERP.

This can lead to a 'leak' of sessions that count for the maximum number of concurrent users, which can result in the limit of concurrent users being reached, when some of those concurrent users belong to sessions that should have been automatically deactivated.
Steps To ReproduceIn a retail environment:
- Log in in the POS. Check that in the ad_session table there is a new session with login_status = 'OBPOS_POS'
- Click on the Back Office button on the Menu. The ERP will open in a new tab. Check that the session now has a login_status = 'S' (ERP)
- Close the ERP tab
- Keep working with the POS window for a few minutes.
- Force the execution of the ActivationKey.deactivateTimeOutSessions method. This method should deactivate all ERP sessions that have been inactive for more than 2 minutes. The session will not be deactivated because, although the last ping was invoked more than 2 minutes ago, it is shared with the POS, where there has been recent activity.

This is a problem because the 'S' session counts for the limit of maximum concurrent users, while the OBPOS_POS session should not count.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to feature request 0032821 closedplatform Mobile Core. Reinforce CU Licensing 
depends on backport 00379003.0PR18Q1 closedalostale Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed 
depends on backport 00379013.0PR17Q4.1 closedalostale Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed 
related to defect 0037893 closedalostale ConcurrentModificationException when working with SessionListener.activeHttpSessions 
related to defect 0037928 closedalostale sys admin sessions created after reaching CU limit are not automatically kicked out 

-  Notes
hgbot (developer)
2018-02-13 12:57

Repository: erp/devel/pi
Changeset: d126554d216bef98a3bea0d94dee2c8ef69a5198
Author: Asier Lostalé <asier.lostale <at>>
Date: Tue Feb 13 12:06:02 2018 +0100
URL: [^]

fixed bug 37893, fixed bug 37899: incorrect CU handling in concurrency and POS

  Concurrent Users management had two different problems:
   * If a backoffice session was reused in POS closing backoffice browser, a CU
     session was counted and it was not deactivated while POS session was active.
     In this situation, the session should be deactivated if CU limit has been
   * Code for creating and checking active http sessions in context was not thread
     safe, so it was possible to get an error when checking if session was active while
     other sessions were created/destroyed in paralell. This has been fixed by
     synchronizing on active session set. Having solved previous issue this should
     not create excessive contentention as it will be executed only if: CU limit has
     been reached and there are sessions created by mobile modules exclude POS.

M src/org/openbravo/erpCommon/obps/
M src/org/openbravo/erpCommon/security/
AugustoMauch (developer)
2018-02-13 13:06

Code reviewed and verified in pi@4f7e83a9ad57
hudsonbot (developer)
2018-02-22 18:19

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
2018-02-13 11:26 AugustoMauch New Issue
2018-02-13 11:26 AugustoMauch Assigned To => alostale
2018-02-13 11:26 AugustoMauch Modules => Core
2018-02-13 11:26 AugustoMauch Triggers an Emergency Pack => No
2018-02-13 11:26 AugustoMauch Relationship added related to 0037893
2018-02-13 12:21 alostale Relationship added related to 0032821
2018-02-13 12:22 alostale Review Assigned To => AugustoMauch
2018-02-13 12:22 alostale Status new => scheduled
2018-02-13 12:57 hgbot Checkin
2018-02-13 12:57 hgbot Note Added: 0102351
2018-02-13 12:57 hgbot Status scheduled => resolved
2018-02-13 12:57 hgbot Resolution open => fixed
2018-02-13 12:57 hgbot Fixed in SCM revision => [^]
2018-02-13 13:06 AugustoMauch Note Added: 0102357
2018-02-13 13:06 AugustoMauch Status resolved => closed
2018-02-13 13:06 AugustoMauch Fixed in Version => 3.0PR18Q2
2018-02-15 12:05 alostale Relationship added related to 0037928
2018-02-22 18:19 hudsonbot Checkin
2018-02-22 18:19 hudsonbot Note Added: 0102750

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker