Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
backport[Openbravo ERP] A. Platformcriticalalways2020-09-07 15:412020-09-09 09:51
ReportermalsasuaView Statuspublic 
Assigned Tocaristu 
PrioritynormalResolutionfixedFixed in VersionPR20Q3.1
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget VersionPR20Q3.1
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toalostale
Web browser
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0045011: 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
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
blocks defect 0045005 closedcaristu In HA environments Data Import Entry processor is executed in the two nodes simultaneously 

-  Notes
hgbot (developer)
2020-09-09 09:39

Repository: [^]
Changeset: 937a72b07e4d25a7c0ccf88928d228231243b45b
Author: Carlos Aristu <>
Date: 2020-09-09T09:28:48+02:00
URL: [^]

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

  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/

- Issue History
Date Modified Username Field Change
2020-09-09 07:07 alostale Type defect => backport
2020-09-09 07:07 alostale Target Version => PR20Q3.1
2020-09-09 09:39 hgbot Resolution open => fixed
2020-09-09 09:39 hgbot Status scheduled => resolved
2020-09-09 09:39 hgbot Fixed in Version => PR20Q3.1
2020-09-09 09:39 hgbot Note Added: 0122855
2020-09-09 09:51 caristu Review Assigned To => alostale
2020-09-09 09:51 caristu Status resolved => closed

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker