Openbravo Issue Tracking System - Openbravo ERP | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0051645 | Openbravo ERP | 04. Warehouse management | public | 2023-02-20 10:41 | 2023-03-16 13:32 |
| Reporter | shuehner | ||||
| Assigned To | tonialcaide | ||||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| Target Version | Fixed in Version | PR23Q2 | |||
| Merge Request Status | |||||
| Review Assigned To | |||||
| OBNetwork customer | |||||
| Web browser | |||||
| Modules | Core | ||||
| Support ticket | |||||
| Regression level | |||||
| Regression date | |||||
| Regression introduced in release | |||||
| Regression introduced by commit | |||||
| Triggers an Emergency Pack | No | ||||
| Summary | 0051645: MaterialReceiptPending.processPurchaseOrder causes idle in transactions to be left (in some cases) | ||||
| Description | Abandoned connection logging points to this file for opening connection marked as suspect: https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/erpCommon/ad_forms/MaterialReceiptPending.java#L326 [^] Checking that function processPurchaseOrder it opens it via getTransactionConnection. It does not have a finally block to 'always' close this connection. However it has several early "return" statements which neither manage this properly: https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/erpCommon/ad_forms/MaterialReceiptPending.java#L370 [^] https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/erpCommon/ad_forms/MaterialReceiptPending.java#L400 [^] https://gitlab.com/openbravo/product/openbravo/-/blob/master/src/org/openbravo/erpCommon/ad_forms/MaterialReceiptPending.java#L417 [^] Likely each of those is a candidate for causing this. Note: While fixing this please also fix up the bad logging (printStackTrace) in that function. | ||||
| Steps To Reproduce | Should be possible to reproduce by: a.) Configuring to lob abandoned connections db.pool.logAbandoned=true db.pool.suspectTimeout=60 # 60s value chose just to aid in debugging b.) Trigger one of the 3 validations listed above + wait at least 60s c.) Check catalina.out, or tomcat console output | ||||
| Proposed Solution | Either: - add properly connection handing to each early return which is missing it - Or add finally block to whole function managing centrally. | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2023-02-20 10:41 | shuehner | New Issue | |||
| 2023-02-20 10:41 | shuehner | Assigned To | => Triage Omni WMS | ||
| 2023-02-20 10:41 | shuehner | Modules | => Core | ||
| 2023-02-20 10:41 | shuehner | Triggers an Emergency Pack | => No | ||
| 2023-02-20 16:22 | tonialcaide | Assigned To | Triage Omni WMS => tonialcaide | ||
| 2023-02-22 11:21 | hgbot | Note Added: 0146864 | |||
| 2023-03-16 13:32 | hgbot | Resolution | open => fixed | ||
| 2023-03-16 13:32 | hgbot | Status | new => closed | ||
| 2023-03-16 13:32 | hgbot | Note Added: 0147605 | |||
| 2023-03-16 13:32 | hgbot | Fixed in Version | => PR23Q2 | ||
| 2023-03-16 13:32 | hgbot | Note Added: 0147606 | |||
| Notes | |||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||