Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0037900Openbravo ERPA. Platformpublic2018-02-13 11:262018-02-13 13:34
AugustoMauch 
alostale 
normalmajorhave not tried
closedfixed 
5
 
3.0PR18Q13.0PR18Q1 
AugustoMauch
Core
No
0037900: 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.
blocks defect 0037899 closed alostale Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed 
Issue History
2018-02-13 12:22alostaleTypedefect => backport
2018-02-13 12:22alostaleTarget Version => 3.0PR18Q1
2018-02-13 12:58hgbotCheckin
2018-02-13 12:58hgbotNote Added: 0102356
2018-02-13 12:58hgbotStatusscheduled => resolved
2018-02-13 12:58hgbotResolutionopen => fixed
2018-02-13 12:58hgbotFixed in SCM revision => http://code.openbravo.com/erp/backports/3.0PR18Q1/rev/ce1a0f24b4ca8280b9f907f6343e4f9da22efa75 [^]
2018-02-13 13:34AugustoMauchNote Added: 0102361
2018-02-13 13:34AugustoMauchStatusresolved => closed
2018-02-13 13:34AugustoMauchFixed in Version => 3.0PR18Q1

Notes
(0102356)
hgbot   
2018-02-13 12:58   
Repository: erp/backports/3.0PR18Q1
Changeset: ce1a0f24b4ca8280b9f907f6343e4f9da22efa75
Author: Asier Lostalé <asier.lostale <at> openbravo.com>
Date: Tue Feb 13 12:06:02 2018 +0100
URL: http://code.openbravo.com/erp/backports/3.0PR18Q1/rev/ce1a0f24b4ca8280b9f907f6343e4f9da22efa75 [^]

fixed bug 37894, fixed bug 37900: 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
---
(0102361)
AugustoMauch   
2018-02-13 13:34   
Code reviewed and verified