Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0053774Openbravo ERPA. Platformpublic2023-10-26 14:072023-10-27 08:48
Reportercaristu 
Assigned Tocaristu 
PriorityhighSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in VersionPR23Q4 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerNo
Web browser
ModulesCore
Support ticket
Regression levelPackaging and release
Regression date2023-08-21
Regression introduced in release
Regression introduced by commithttps://gitlab.com/openbravo/product/openbravo/-/commit/03fa452e48c60b06e2f1a70f29a093bbf07004d0 [^]
Triggers an Emergency PackNo
Summary0053774: RO pool is not closed by IE threads
DescriptionIf the process executed by an Import Entry makes use of the RO pool, then the transactions of that pool are never closed.
Steps To Reproduce1) Configure the RO pool
2) In the "External System" window, create a new external system
3) In the "Event Subscription" window, create an event subscription for the "Resend Orders" event and for the external system created in step 2). Note that being a multiple record event, the RO pool is used by default to get the data.
4) Trigger the event doing (see attached patch):
      SynchronizationEvent.getInstance()
        .triggerEvent("API_ResendOrders",
            Map.of("orders", List.of("E1987F8E432041BD9F81D3DD29D6D4CB")));
5) In database, run: select count(*) from pg_stat_activity where state ilike '%in transaction%';

Note that the count of "idle in transaction" connections is increased every time the event is triggered
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
depends on backport 0053779PR23Q4 closed caristu RO pool is not closed by IE threads 
caused by feature request 0052614 closed cberner There should be a mechanism to have non-blocking async EDL Requests 
Attached Filesdiff About.diff (1,326) 2023-10-26 14:23
https://issues.openbravo.com/file_download.php?file_id=19101&type=bug
Issue History
Date ModifiedUsernameFieldChange
2023-10-26 14:07caristuNew Issue
2023-10-26 14:07caristuAssigned To => caristu
2023-10-26 14:07caristuOBNetwork customer => No
2023-10-26 14:07caristuModules => Core
2023-10-26 14:07caristuTriggers an Emergency Pack => No
2023-10-26 14:09hgbotMerge Request Status => open
2023-10-26 14:09hgbotNote Added: 0156328
2023-10-26 14:23caristuFile Added: About.diff
2023-10-26 14:24caristuSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=27045#r27045
2023-10-26 17:17rafarodaRelationship addedrelated to 0052614
2023-10-26 18:05caristuRelationship deletedrelated to 0052614
2023-10-26 18:06caristuRelationship addedcaused by 0052614
2023-10-26 18:07caristuRegression level => Packaging and release
2023-10-26 18:07caristuRegression date => 2023-08-21
2023-10-26 18:08caristuStatusnew => scheduled
2023-10-27 07:34alostaleRegression introduced by commit => https://gitlab.com/openbravo/product/openbravo/-/commit/03fa452e48c60b06e2f1a70f29a093bbf07004d0 [^]
2023-10-27 08:48hgbotMerge Request Statusopen => approved
2023-10-27 08:48hgbotNote Added: 0156433
2023-10-27 08:48hgbotResolutionopen => fixed
2023-10-27 08:48hgbotStatusscheduled => closed
2023-10-27 08:48hgbotFixed in Version => PR24Q1
2023-10-27 08:48hgbotNote Added: 0156434
2023-10-27 08:48hgbotFixed in VersionPR24Q1 => PR23Q4
2023-10-27 08:48hgbotNote Added: 0156435

Notes
(0156328)
hgbot   
2023-10-26 14:09   
Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/1029 [^]
(0156433)
hgbot   
2023-10-27 08:48   
Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/1029 [^]
(0156434)
hgbot   
2023-10-27 08:48   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: 8f74368a0f9313d57074758d01016d685ed090fe
Author: Carlos Aristu <carlos.aristu@openbravo.com>
Date: 26-10-2023 16:19:04
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/8f74368a0f9313d57074758d01016d685ed090fe [^]

fixes BUG-53774: RO pool is never closed by IE threads

  If a process executed in an import entry used the RO pool, the
connection was not being closed properly by the infrastructure under
some circumstances.

  We had different scenarios depending on the process being executed in
the import entry thread:

  - If the process executed was a blocking EDL process, the RO pool
session was being always closed because the postProcessEntry method was
invoked using the SessionHandler that had the reference to the open
session.

  - If the process executed in the import entry was a non-blocking EDL
process, the RO pool session was NOT being closed because the
postProcessEntry method used a SessionHandler which do not have the
reference to the open session, because it was invoked by a different
thread.

  - If the process was not an EDL process, the RO pool was being closed
in case the process was executed without errors. If the process failed,
the RO pool session was not being closed.

  Now we fix the two scenarios where the session was not being closed.

Note that for the case of a successful execution we now use
DalThreadCleaner().getInstance.cleanWithCommit() method for consistency
and to avoid some small code duplicity.

---
M src/org/openbravo/service/importprocess/ImportEntryProcessor.java
---
(0156435)
hgbot   
2023-10-27 08:48   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: bb1afc38f7ba4919b7f534de3015576e98368547
Author: Carlos Aristu <carlos.aristu@openbravo.com>
Date: 26-10-2023 16:16:56
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/bb1afc38f7ba4919b7f534de3015576e98368547 [^]

fixes BUG-53774: RO pool is never closed by IE threads

  If a process executed in an import entry used the RO pool, the
connection was not being closed properly by the infrastructure under
some circumstances.

  We had different scenarios depending on the process being executed in
the import entry thread:

  - If the process executed was a blocking EDL process, the RO pool
session was being always closed because the postProcessEntry method was
invoked using the SessionHandler that had the reference to the open
session.

  - If the process executed in the import entry was a non-blocking EDL
process, the RO pool session was NOT being closed because the
postProcessEntry method used a SessionHandler which do not have the
reference to the open session, because it was invoked by a different
thread.

  - If the process was not an EDL process, the RO pool was being closed
in case the process was executed without errors. If the process failed,
the RO pool session was not being closed.

  Now we fix the two scenarios where the session was not being closed.

Note that for the case of a successful execution we now use
DalThreadCleaner().getInstance.cleanWithCommit() method for consistency
and to avoid some small code duplicity.

---
M src/org/openbravo/service/importprocess/ImportEntryProcessor.java
---