Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0037899 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Openbravo ERP] A. Platform | major | have not tried | 2018-02-13 11:26 | 2018-02-22 18:19 | |||
| Reporter | AugustoMauch | View Status | public | |||||
| Assigned To | alostale | |||||||
| Priority | normal | Resolution | fixed | Fixed in Version | 3.0PR18Q2 | |||
| Status | closed | Fix in branch | Fixed in SCM revision | d126554d216b | ||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Review Assigned To | AugustoMauch | |||||||
| Web browser | ||||||||
| Modules | Core | |||||||
| Regression level | ||||||||
| Regression date | ||||||||
| Regression introduced in release | ||||||||
| Regression introduced by commit | ||||||||
| Triggers an Emergency Pack | No | |||||||
| Summary | 0037899: 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. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
 Relationships |
|
Notes |
|
|
(0102351) hgbot (developer) 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 (manager) 2018-02-13 13:06 |
Code reviewed and verified in pi@4f7e83a9ad57 |
|
(0102750) 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: https://code.openbravo.com/erp/devel/main/rev/980a6ad5bbf5 [^] Maturity status: Test |
|
Notes |
|
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 | => http://code.openbravo.com/erp/devel/pi/rev/d126554d216bef98a3bea0d94dee2c8ef69a5198 [^] |
| 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 | |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |