|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|backport||[Openbravo ERP] A. Platform||major||have not tried||2018-02-13 11:26||2018-02-13 13:34|
|Priority||normal||Resolution||fixed||Fixed in Version||3.0PR18Q1|
|Status||closed||Fix in branch||Fixed in SCM revision||ce1a0f24b4ca|
|OS Version||Database version||Ant version|
|Product Version||SCM revision|
|Review Assigned To||AugustoMauch|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0037900: Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed
|Description||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.
|Steps To Reproduce||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.
|Tags||No tags attached.|
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
* 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.
|Code reviewed and verified|
|2018-02-13 12:22||alostale||Type||defect => backport|
|2018-02-13 12:22||alostale||Target Version||=> 3.0PR18Q1|
|2018-02-13 12:58||hgbot||Note Added: 0102356|
|2018-02-13 12:58||hgbot||Status||scheduled => resolved|
|2018-02-13 12:58||hgbot||Resolution||open => fixed|
|2018-02-13 12:58||hgbot||Fixed in SCM revision||=> http://code.openbravo.com/erp/backports/3.0PR18Q1/rev/ce1a0f24b4ca8280b9f907f6343e4f9da22efa75 [^]|
|2018-02-13 13:34||AugustoMauch||Note Added: 0102361|
|2018-02-13 13:34||AugustoMauch||Status||resolved => closed|
|2018-02-13 13:34||AugustoMauch||Fixed in Version||=> 3.0PR18Q1|
|Copyright © 2000 - 2009 MantisBT Group|