Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0045005Openbravo ERPA. Platformpublic2020-09-07 15:412020-09-09 09:20
Reportermalsasua 
Assigned Tocaristu 
PrioritynormalSeveritycriticalReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in VersionPR20Q4 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerGold
Web browser
ModulesCore
Support ticket17659
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0045005: In HA environments Data Import Entry processor is executed in the two nodes simultaneously
DescriptionIn 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
Steps To ReproduceWe 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
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
depends on backport 0045011PR20Q3.1 closed caristu In HA environments Data Import Entry processor is executed in the two nodes simultaneously 
depends on backport 0045012PR20Q2.2 closed caristu In HA environments Data Import Entry processor is executed in the two nodes simultaneously 
Attached Filespng db_locks.png (86,797) 2020-09-07 15:41
https://issues.openbravo.com/file_download.php?file_id=14946&type=bug
png

log example.log (68,377) 2020-09-07 15:41
https://issues.openbravo.com/file_download.php?file_id=14947&type=bug
Issue History
Date ModifiedUsernameFieldChange
2020-09-07 15:41malsasuaNew Issue
2020-09-07 15:41malsasuaAssigned To => platform
2020-09-07 15:41malsasuaFile Added: db_locks.png
2020-09-07 15:41malsasuaOBNetwork customer => Gold
2020-09-07 15:41malsasuaModules => Core
2020-09-07 15:41malsasuaResolution time => 1600639200
2020-09-07 15:41malsasuaTriggers an Emergency Pack => No
2020-09-07 15:41malsasuaFile Added: example.log
2020-09-07 15:45malsasuaSupport ticket => 17659
2020-09-08 18:10hgbotMerge Request Status => open
2020-09-08 18:10hgbotNote Added: 0122805
2020-09-09 07:07alostaleAssigned Toplatform => caristu
2020-09-09 07:07alostaleSeveritymajor => critical
2020-09-09 07:07alostaleStatusnew => scheduled
2020-09-09 09:13hgbotMerge Request Statusopen => approved
2020-09-09 09:20hgbotResolutionopen => fixed
2020-09-09 09:20hgbotStatusscheduled => closed
2020-09-09 09:20hgbotNote Added: 0122852
2020-09-09 09:20hgbotFixed in Version => PR20Q4
2020-09-09 09:20hgbotNote Added: 0122853

Notes
(0122805)
hgbot   
2020-09-08 18:10   
Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/152 [^]
(0122852)
hgbot   
2020-09-09 09:20   
Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/152 [^]
(0122853)
hgbot   
2020-09-09 09:20   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: 3f3600da371663ecc80dce4fa215a6138bd11e11
Author: Carlos Aristu <carlos.aristu@openbravo.com>
Date: 2020-09-09T09:20:11+02:00
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/3f3600da371663ecc80dce4fa215a6138bd11e11 [^]

fixes ISSUE-45005: 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
---