Anonymous | Login

Project:

News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ]

[ Issue History ] [ Print ]

ID

0052455

Type

Category

Severity

Reproducibility

Date Submitted

Last Update

defect

[Openbravo ERP] A. Platform

major

random

2023-05-16 09:45

2025-01-10 02:59

Reporter

gorkaion

View Status

public

Assigned To

caristu

Priority

high

Resolution

duplicate

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

SCM revision

Merge Request Status

Review Assigned To

caristu

OBNetwork customer

Gold

Web browser

Modules

Core

Support ticket

64183

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

No

Summary

0052455: Import Entry processed twice when processing node is changed

Description

On a clustered environment with 2 application nodes.

If the node handling import entries is changed from node A to node B while node A is still processing Import Entries.

When the node B start processing it searches import entries and queue some that are also queued and to be processed in node A.

These Import Entries are processed in both nodes. When the Import Entry is 1st processed by node B and later in node A.

The Import Entry processed in node B ends with success.

The Import Entry processed in node A can fail generating a false error or duplicating a processing.

In case of POS requests like Order Loader the process generates a Error While Importing with an OutdatedDateException.
In case of a Integration request the process might send again the same data to the external system generating a duplicate.

Steps To Reproduce

Rough steps:
- Build a cluster environment with node A and B.
- Generate some Import Entries.
- When all Import Entries are queued in node A switch to node B.
- node B queue all the Import Entries again.
- Make the processing in node A slower so a Import Entry is processed first in node B
- Check that this import entry is processed again in node A with unpredictable results.

Proposed Solution

- Before starting to process an Import Entry check the status of the Import Entry to avoid processing again a Import Entry that it is not in Initial status anymore.

- Additionally consider to add a delay time when the handling node is switch before starting to search for new Import Entries to allow the node A to process queues entries.

Tags

No tags attached.

Relationships [ Relation Graph ] [ Dependency Graph ]

duplicate of	defect	0048454		closed	caristu	When a node is demoted as cluster node IE can be processed twice under some circumstances
related to	defect	0052457		closed	Triage Platform Conn	On cluster environments processing node can be switch even if current node is alive
related to	defect	0052445		closed	AugustoMauch	The margin when checking if we need to replace a cluster instance is too small
related to	defect	0052456		closed	caristu	Import Entry post process hook not executed when processing node is changed

Notes
There are no notes attached to this issue.

Issue History
Date Modified	Username	Field	Change
2023-05-16 09:45	gorkaion	New Issue
2023-05-16 09:45	gorkaion	Assigned To	=> Triage Platform Conn
2023-05-16 09:45	gorkaion	OBNetwork customer	=> No
2023-05-16 09:45	gorkaion	Modules	=> Core
2023-05-16 09:45	gorkaion	Triggers an Emergency Pack	=> No
2023-05-16 10:17	gorkaion	Issue cloned	0052456
2023-05-16 10:17	gorkaion	Relationship added	related to 0052456
2023-05-16 10:29	gorkaion	OBNetwork customer	No => Gold
2023-05-16 10:29	gorkaion	Support ticket	=> 64183
2023-05-16 10:30	gorkaion	Relationship added	related to 0052457
2023-05-16 10:31	gorkaion	Relationship added	related to 0052445
2023-05-18 14:33	ngarcia	Issue Monitored: ngarcia
2023-05-18 17:09	adrianromero	Assigned To	Triage Platform Conn => caristu
2023-05-19 11:36	caristu	Relationship added	related to 0048454
2023-05-22 11:45	caristu	Relationship deleted	related to 0048454
2023-05-22 11:46	caristu	Relationship added	duplicate of 0048454
2023-05-22 11:46	caristu	Review Assigned To	=> caristu
2023-05-22 11:46	caristu	Status	new => closed
2023-05-22 11:46	caristu	Resolution	open => duplicate
2025-01-10 02:59	helendam	Note Added: 0173967

Copyright © 2000 - 2009 MantisBT Group