Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 04. Warehouse managementmajoralways2020-08-13 13:562020-09-25 09:06
ReporterdavidverrierView Statuspublic 
Assigned Tovmromanos 
PriorityurgentResolutionunable to reproduceFixed in Version
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product Version3.0PR19Q3.4SCM revision 
Review Assigned Tovmromanos
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0044809: AWO consumes sessions without releasing them

DescriptionWhen 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 Reproduce1. 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.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
vmromanos (developer)
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.

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