Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0044809Openbravo ERP04. Warehouse managementpublic2020-08-13 13:562020-09-25 09:06
davidverrier 
vmromanos 
urgentmajoralways
closedunable to reproduce 
5
3.0PR19Q3.4 
 
vmromanos
Core
No
0044809: AWO consumes sessions without releasing them
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.
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
4. wait
5. Eventually runs out of sessions.
No tags attached.
Issue History
2020-08-13 13:56davidverrierNew Issue
2020-08-13 13:56davidverrierAssigned To => Triage Finance
2020-08-13 13:56davidverrierModules => Core
2020-08-13 13:56davidverrierTriggers an Emergency Pack => No
2020-08-24 08:27dmiguelezAssigned ToTriage Finance => guilleaer
2020-09-17 00:01dmitry_mezentsevSeveritycritical => major
2020-09-24 09:53guilleaerAssigned Toguilleaer => vmromanos
2020-09-25 09:06vmromanosReview Assigned To => vmromanos
2020-09-25 09:06vmromanosNote Added: 0123369
2020-09-25 09:06vmromanosStatusnew => closed
2020-09-25 09:06vmromanosResolutionopen => unable to reproduce

Notes
(0123369)
vmromanos   
2020-09-25 09:06   
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.