Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0037900
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Openbravo ERP] A. Platformmajorhave not tried2018-02-13 11:262018-02-13 13:34
ReporterAugustoMauchView Statuspublic 
Assigned Toalostale 
PrioritynormalResolutionfixedFixed in Version3.0PR18Q1
StatusclosedFix in branchFixed in SCM revisionce1a0f24b4ca
ProjectionnoneETAnoneTarget Version3.0PR18Q1
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned ToAugustoMauch
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0037900: 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 ]
blocks defect 0037899 closedalostale Session in POS can prevent an ERP session (which counts for concurrent user limit) from being closed 

-  Notes
(0102356)
hgbot (developer)
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 (administrator)
2018-02-13 13:34

 Code reviewed and verified

- Issue History
Date Modified Username Field Change
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 Checkin
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
Powered by Mantis Bugtracker