|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|defect||[Openbravo ERP] 04. Warehouse management||major||always||2020-08-13 13:56||2020-09-25 09:06|
|Priority||urgent||Resolution||unable to reproduce||Fixed in Version|
|Status||closed||Fix in branch||Fixed in SCM revision|
|OS Version||Database version||Ant version|
|Product Version||3.0PR19Q3.4||SCM revision|
|Review Assigned To||vmromanos|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0044809: AWO consumes sessions without releasing them
|Description||When I change the preference "Limit of Tasks Assigned per User" to something over the default value of 100, such as 300,|
After the process for generating picking tasks is started (and that there are tasks to generate)
Eventually AWO runs out of sessions, and we cannot log in anymore.
|Steps To Reproduce||1. set "Limit of Tasks Assigned per User" to 300|
2. create an order (or multiple orders) with lines totaling over 150
3. start picking task generator process
5. Eventually runs out of sessions.
|Tags||No tags attached.|
Unable to reproduce the issue with the provided steps.
What I have tried:
In an standard environment with the last AWO code and inside the AWO sampledata client
Increase the "Limit of Tasks Assigned per User" preference to 300
In the Warehouse Definition, configure two Task Assignment rules, one with "Rule to Task" and another one with "Task to Rules". Assign both records to any operator.
Create a Purchase Order and enter more than 200 lines.
Book the order.
Run the receive and do not assign it to any user. It works OK.
Go to Process Request window and create a new record for * org, "Task Assignment" process and run it immediately. It works fine and it assigns the newly created tasks to the same operator.
I have repeated the same example with a Sales Order picking and the full process works fine too.
When reading the issue description and the error stack trace I initially thought there could be a problem in the Operator Load Balancing code when clearing the hibernate session. However, I haven't been able to reproduce it.
On the other hand, the problem with the license's sessions raised in this issue too is very unlikely to be related with this AWO problem. A process that fails doesn't consume (or leak) license's sessions. If the process is launched in the background for sure it has nothing to do with the license's sessions. And if the failing process is launched by an user from the UI, the license's session will be closed with the user's session or after a defined timeout, regardless the process has failed or not.
The only possibility we might imagine is that you're using a very custom way to launch processes, like for example through a custom web service call. In this case, depending on the implementation, you might face the problems with the license's sessions.
I'm rejecting the issue now. If you are able to reproduce with the last version of the code in an standard instance, please reopen the issue and provide more details and better steps to reproduce.
|2020-08-13 13:56||davidverrier||New Issue|
|2020-08-13 13:56||davidverrier||Assigned To||=> Triage Finance|
|2020-08-13 13:56||davidverrier||Modules||=> Core|
|2020-08-13 13:56||davidverrier||Triggers an Emergency Pack||=> No|
|2020-08-24 08:27||dmiguelez||Assigned To||Triage Finance => guilleaer|
|2020-09-17 00:01||dmitry_mezentsev||Severity||critical => major|
|2020-09-24 09:53||guilleaer||Assigned To||guilleaer => vmromanos|
|2020-09-25 09:06||vmromanos||Review Assigned To||=> vmromanos|
|2020-09-25 09:06||vmromanos||Note Added: 0123369|
|2020-09-25 09:06||vmromanos||Status||new => closed|
|2020-09-25 09:06||vmromanos||Resolution||open => unable to reproduce|
|Copyright © 2000 - 2009 MantisBT Group|