Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0045012Openbravo ERPA. Platformpublic2020-09-07 15:412020-09-09 09:51
malsasua 
caristu 
normalcriticalalways
closedfixed 
5
 
PR20Q2.2PR20Q2.2 
alostale
Core
No
0045012: In HA environments Data Import Entry processor is executed in the two nodes simultaneously
In environments with more than one tomcat node, in some cases, the Data Import Entry processor can be executed at the same time in the two nodes
We have found the problem in environments with database locks (attachment1)
See one example: attachment2

For this case, it seems that only during 16 seconds, the records were processed simultaneously
No tags attached.
blocks defect 0045005 closed caristu In HA environments Data Import Entry processor is executed in the two nodes simultaneously 
Issue History
2020-09-09 07:07alostaleTypedefect => backport
2020-09-09 07:07alostaleTarget Version => PR20Q2.2
2020-09-09 09:39hgbotResolutionopen => fixed
2020-09-09 09:39hgbotStatusscheduled => resolved
2020-09-09 09:39hgbotFixed in Version => PR20Q2.2
2020-09-09 09:39hgbotNote Added: 0122857
2020-09-09 09:51caristuReview Assigned To => alostale
2020-09-09 09:51caristuStatusresolved => closed

Notes
(0122857)
hgbot   
2020-09-09 09:39   
Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: 8eaa60e0a0696550797be3f75ab7bca3870fc045
Author: Carlos Aristu <carlos.aristu@openbravo.com>
Date: 2020-09-09T09:31:59+02:00
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/8eaa60e0a0696550797be3f75ab7bca3870fc045 [^]

fixes ISSUE-45012: can have two leader nodes at the same time

   In case of having a database lock in the AD_CLUSTER_SERVICE table,
the nodes of the HA clustered environment are not able to update
properly the last ping information. This may cause that during a period
of time several nodes of the claster to wrongly take the leadership.

  The database lock causes the nodes to detect that the leader is no longer
available and to try to register themselves as leaders which will not
be possible while the table is locked.

  Once the lock is resolved, the different updates from the nodes will
be executed, causing a temporary wrong registration of one of the nodes as
leader.

  To avoid this wrong registration (update) in the table, we are going
to take into account the last ping seeing by each node when updating the
record. Thus, when the lock is resolved the leader update will be
commited updating the last ping value. Then, the rest of nodes will not
be able to update the record as the change in the last ping value will
make their update where clause not be fullfiled.

  Together with this change, we are removing some empty comments used to
format and removing a no longer needed string concatenation for logging.

---
M src/org/openbravo/cluster/ClusterServiceManager.java
---