[
https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585816#comment-13585816
]
Gary Tully commented on AMQ-4122:
---------------------------------
@SouNayi - thanks for the feedback. on {quote}The cause is that
LeaseDatabaseLocker always succeed updating the broker name (the owner of the
lease lock) by later lease time in contrast to the current lease owner.{quote}
Can you make a variant of
https://fisheye6.atlassian.com/viewrep/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/store/jdbc/LeaseDatabaseLockerTest.java
that shows the problem? I don't see a problem against derby in the unit test.
Note: in the unit test there is no periodic call to keepalive.
The intent of the update to acquire a lock checks the TIME value against
current time and sets it to obtain the lease. It should (and does) fail if the
lease is still valid. ie: the time is set to a value in the
future.https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#
> Lease Database Locker failover broken
> -------------------------------------
>
> Key: AMQ-4122
> URL: https://issues.apache.org/jira/browse/AMQ-4122
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.7.0
> Environment: Java 7u9, SUSE 11, Mysql
> Reporter: st.h
> Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: activemq-kyle.xml, activemq.xml, activemq.xml,
> AMQ4122.patch, mysql.log
>
>
> We are using ActiveMQ 5.7.0 together with a mysql database and could not
> observe correct failover behavior with lease database locker.
> It seems that there is a race condition, which prevents the correct failover
> procedure.
> We noticed that when starting up two instances, both instance are becoming
> master.
> We did several test, including the following and could not observe intended
> functionality:
> - shutdown all instances
> - manipulate database lock that one node has lock and set expiry time in
> distance future
> - start up both instances. both instances are unable to acquire lock, as the
> lock hasn't expired, which should be correct behavior.
> - update the expiry time in database, so that the lock is expired.
> - first instance notices expired lock and becomes master
> - when second instance checks for lock, it also updates the database and
> becomes master.
> To my understanding the second instance should not be able to update the
> lock, as it is held by the first instance and should not be able to become
> master.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
