0048427: high load of low priority import entries can cause higher priority entries not to be processed

Openbravo Issue Tracking System - Openbravo ERP

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0048427

Openbravo ERP

A. Platform

public

2022-01-19 13:04

2022-11-28 23:54

Reporter

alostale

Assigned To

alostale

Priority

normal

Severity

major

Reproducibility

have not tried

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

Fixed in Version

PR22Q3

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

Summary

0048427: high load of low priority import entries can cause higher priority entries not to be processed

Description

Having the following import entry types:

1. OBUIELS_Data1
  It has a higher priority (1)

2. OBUIELS_Data2
  It has a lower priority (2)
  It takes long to process each entry
  Its entries span their keys to consume all the threads
  It has a high inflow of entries to process

The import entry type with the lowest priority (OBUIELS_Data2) can take all the processing capacity till it finishes so the one with the highest priority (OBUIELS_Data1) has no throughput till all (or most) the entries from OBUIELS_Data2 are processed. See the attached graph which represents how many entries of each type are pending to be processed over the time.

This issue is caused because:

1. 1st Import Entry manger loop starts:
1.1. It schedules 5000 (batch size) OBUIELS_Data2 entries, they are distributed by key (up to 10) consuming all the available threads. After they are scheduled Import Entry manager thread waits some time before resuming with 2nd loop

2. After wait time elapsed, 2nd loop starts:
2.1. It first submits to be scheduled OBUIELS_Data1 type entries (with a higher priority). As there are still OBUIELS_Data2 entries from the previous cycle pending to be processed OBUIELS_Data1 entries are queued to be processed once previously scheduled entries are done.
2.2. There are new OBUIELS_Data2 entries they are scheduled. The problem is they are assigned, based on their key, to import processor runnables that were created in the previous cycle and are still processing. Because of this, these runnables, after processing entries from the previous loop will process the ones that have just been scheduled, not allowing the OBUIELS_Data1 processors to start till they are done.

Steps To Reproduce

This scenario can be simulated with Entry Load Simulator [1] and the following config:

** Import Entry config
  import.batch.size                     5000
  import.number.of.threads              11
  import.max.task.queue.size            1000
  import.wait.time                      600
  import.processing.capacity.per.second 330
** OBUIELS_Data1
  Num of Entries 10
  Period         200
  Cycles         50
  Delay          50
  Exec Time      50
  # of Keys      50
** OBUIELS_Data2
  Num of Entries 200
  Period         100
  Cycles         15
  Delay          0
  Exec Time      750
  # of Keys      10

[1] https://gitlab.com/openbravo/tools/platform/org.openbravo.util.ieloadsim [^]

Proposed Solution

Additional Information

Tags

NOR

Relationships

related to	defect	0048418	new	Triage Platform Conn	Openbravo ERP	import entries can be processed twice if their key is not deterministic
related to	defect	0045145	closed	ranjith_qualiantech_com	Retail Modules	Priority not defined for Session Import types
related to	defect	0049963	closed	Triage Platform Base	Openbravo ERP	When a ImportEntry is not assigned to a runnable it should not be included in hte entryCount
related to	defect	0047219	closed	caristu	Modules	Use different runnables for EDL processes that should be executed in a specific thread