Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 8 Nov 2012 17:42:14 +0000 (UTC)
From: "Justin Field (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <1339638058.87527.1352396534275.JavaMail.jiratomcat@arcas>
In-Reply-To: <215600322.10206.1350922092933.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (AMQ-4122) Lease Database Locker failover broken
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Justin Field commented on AMQ-4122:
-----------------------------------

I was never able to resolve the issue so i mad the following work around

https://gist.github.com/4040309
                
> 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, 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