[ 
https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483533#comment-13483533
 ] 

Gary Tully commented on AMQ-4122:
---------------------------------

thanks for the config Christoph, I went ahead and built a simple unit test 
based on your description. It works fine. Maybe I need to add more contention, 
ie: more locks to try and replicate a race condition. The locker currently 
verifies that it succeeded in acquiring the lock by doing a lease extend 
immediately after, so it should be safe but there may be need for a random 
pause in there.
Can you peek at the test case and see if it reflects your use case and is 
possible modify it such that it breaks?
http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/store/jdbc/LeaseDatabaseLockerTest.java?view=diff&r1=1401848&r2=1401849&pathrev=1401849
                
> 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
>         Attachments: activemq.xml
>
>
> 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

Reply via email to