Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0037899Openbravo ERPA. Platformpublic2018-02-13 11:262018-02-22 18:19
AugustoMauch 
alostale 
normalmajorhave not tried
closedfixed 
5
 
3.0PR18Q2 
AugustoMauch
Core
No
0037899: Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed
POS 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.
In 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.
No tags attached.
related to feature request 0032821 closed platform Mobile Core. Reinforce CU Licensing 
depends on backport 00379003.0PR18Q1 closed alostale Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed 
depends on backport 00379013.0PR17Q4.1 closed alostale Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed 
related to defect 0037893 closed alostale ConcurrentModificationException when working with SessionListener.activeHttpSessions 
related to defect 0037928 closed alostale sys admin sessions created after reaching CU limit are not automatically kicked out 
Issue History
2018-02-13 11:26AugustoMauchNew Issue
2018-02-13 11:26AugustoMauchAssigned To => alostale
2018-02-13 11:26AugustoMauchModules => Core
2018-02-13 11:26AugustoMauchTriggers an Emergency Pack => No
2018-02-13 11:26AugustoMauchRelationship addedrelated to 0037893
2018-02-13 12:21alostaleRelationship addedrelated to 0032821
2018-02-13 12:22alostaleReview Assigned To => AugustoMauch
2018-02-13 12:22alostaleStatusnew => scheduled
2018-02-13 12:57hgbotCheckin
2018-02-13 12:57hgbotNote Added: 0102351
2018-02-13 12:57hgbotStatusscheduled => resolved
2018-02-13 12:57hgbotResolutionopen => fixed
2018-02-13 12:57hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/d126554d216bef98a3bea0d94dee2c8ef69a5198 [^]
2018-02-13 13:06AugustoMauchNote Added: 0102357
2018-02-13 13:06AugustoMauchStatusresolved => closed
2018-02-13 13:06AugustoMauchFixed in Version => 3.0PR18Q2
2018-02-15 12:05alostaleRelationship addedrelated to 0037928
2018-02-22 18:19hudsonbotCheckin
2018-02-22 18:19hudsonbotNote Added: 0102750

Notes
(0102351)
hgbot   
2018-02-13 12:57   
Repository: erp/devel/pi
Changeset: d126554d216bef98a3bea0d94dee2c8ef69a5198
Author: Asier Lostalé <asier.lostale <at> openbravo.com>
Date: Tue Feb 13 12:06:02 2018 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/d126554d216bef98a3bea0d94dee2c8ef69a5198 [^]

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
     reached.
   * 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/ActivationKey.java
M src/org/openbravo/erpCommon/security/SessionListener.java
---
(0102357)
AugustoMauch   
2018-02-13 13:06   
Code reviewed and verified in pi@4f7e83a9ad57
(0102750)
hudsonbot   
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: https://code.openbravo.com/erp/devel/main/rev/980a6ad5bbf5 [^]
Maturity status: Test