Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0044809 | ||||||||
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 | |||
Reporter | davidverrier | View Status | public | |||||
Assigned To | vmromanos | |||||||
Priority | urgent | Resolution | unable to reproduce | Fixed in Version | ||||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | ||||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | 3.0PR19Q3.4 | SCM revision | ||||||
Review Assigned To | vmromanos | |||||||
Web browser | ||||||||
Modules | Core | |||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 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 4. wait 5. Eventually runs out of sessions. | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |
Notes | |
(0123369) vmromanos (manager) 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 |