Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0047139
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformcriticalhave not tried2021-06-15 12:352022-04-03 19:36
ReporterAugustoMauchView Statuspublic 
Assigned ToAugustoMauch 
PrioritynormalResolutionfixedFixed in VersionPR21Q3
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0047139: Import entries can be permanently left unprocessed, in Initial status

DescriptionThe ImportEntryManager uses a ThreadPoolExecutor to execute import entries concurrently. The ThreadPoolExecutor uses an ArrayBlockingQueue to store the tasks before they are executed. By default that queue has a maximum capacity of 1000, that value can be configured by setting a different value on the import.max.task.queue.size property.

If a new Runnable is submitted to the ThreadPoolExecutor once its queue has reached the maximum capacity, and exception will be thrown and the Runnable will not be added. The problem is that even though the Runnable is not actually submitted, ImportEntryProcessRunnable that summited that runnable is caching it, and as a consequence it determines that is already being executed, and is not trying to resubmit it. When that happens, the import entries that are part of the reject Runnables will be permanently left in Initial status, until the server is restarted.

For the issue to be reproduced, several factors must occur at the same time:
- The import entry processing throughput is not able to keep up with the demand, so the queue grows until reaching its maximum capacity
- The combination of (type of data, organization) is very high. Usually there is a runnable for each (type of data, organization) combination (each processor can define its own rules). If the combination was lower than the capacity of the queue the issue would not be reproduced.



Steps To ReproduceThis issue was reproduced by running a performance test on an environment with following characteristics:
- 711 organizations
- 15 different import entry type of data

The reproducibility was quite random until we reduced to 20 the number of available connections in the pool. This reduction resulted in the processing of the import entries being much slower, and as a consequence the import entry manager was not able to keep up with the demand, and the task queue reached its maximum capacity.

Once the performance test was run under these conditions, some import entries were left in Initial Status, and they were not processed until the server was restarted.
TagsNOR
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
depends on backport 0047144PR21Q2.1 closedAugustoMauch Openbravo ERP Import entries can be permanently left unprocessed, in Initial status 
depends on backport 0047145PR21Q1.4 closedAugustoMauch Openbravo ERP Import entries can be permanently left unprocessed, in Initial status 
depends on defect 0047146 closedplatform Openbravo ERP API change: update visibility of ImportEntryManager.submitRunnable from public to package 
related to defect 0047219 closedcaristu Modules Use different runnables for EDL processes that should be executed in a specific thread 

-  Notes
(0129514)
hgbot (developer)
2021-06-15 14:10

Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/396 [^]
(0129535)
hgbot (developer)
2021-06-16 07:31

Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/396 [^]
(0129536)
hgbot (developer)
2021-06-16 07:31

Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: 23124a1311f1c66ecc36ea45d5e8b05733502a64
Author: Augusto Mauch <augusto.mauch@openbravo.com>
Date: 2021-06-16T05:31:06+00:00
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/23124a1311f1c66ecc36ea45d5e8b05733502a64 [^]

Fixes ISSUE-47139: Import entries can be permanently left unprocessed

The problem was that it was possible for ImportEntryProcessor to cache a Runnable assuming that it had been
properly submitted to a executorService, when in reality the submission had failed (i.e. because the queue
of the executorService was at maximum capacity).

This has been fixed by ensuring that the runnable is not cached until ensuring that it has been properly
submitted.

The visibility of the submitRunnable method has been changed to package, because there is only need for
ImportEntryProcessor to have access to it.

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

- Issue History
Date Modified Username Field Change
2021-06-15 12:35 AugustoMauch New Issue
2021-06-15 12:35 AugustoMauch Assigned To => AugustoMauch
2021-06-15 12:35 AugustoMauch Modules => Core
2021-06-15 12:35 AugustoMauch Triggers an Emergency Pack => No
2021-06-15 14:10 hgbot Note Added: 0129514
2021-06-15 14:14 AugustoMauch Status new => scheduled
2021-06-16 07:28 alostale Relationship added depends on 0047146
2021-06-16 07:31 hgbot Resolution open => fixed
2021-06-16 07:31 hgbot Status scheduled => closed
2021-06-16 07:31 hgbot Note Added: 0129535
2021-06-16 07:31 hgbot Fixed in Version => PR21Q3
2021-06-16 07:31 hgbot Note Added: 0129536
2021-06-16 11:34 rafaroda Tag Attached: NOR
2021-06-29 22:47 rafaroda Relationship added related to 0047219
2022-04-03 19:36 eugeni Issue Monitored: eugeni


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker