[
https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493329#comment-13493329
]
Justin Field edited comment on AMQ-4122 at 11/8/12 6:45 PM:
------------------------------------------------------------
I was never able to resolve the issue so i made the following work around
I basically have each broker query the db to get who the current Master should
be (based of the brokers hostname)
compare it to its host name and check the isSlave value. if there is a
discrepancy I shut the broker down and create a new one.
ActiveMQ Broker Monitor
https://gist.github.com/4040309
ActiveMQ bean definitions / configuration
https://gist.github.com/4040646
Parallel Ingestion ActiveMQ Manager
https://gist.github.com/4fc5669d41f25072d2f4
Broker Factory (see bean definition in ActiveMQ bean definitions)
https://gist.github.com/8ad9cf6ace9245c63f41
was (Author: fieldju):
I was never able to resolve the issue so i made the following work around
ActiveMQ Broker Monitor
https://gist.github.com/4040309
ActiveMQ bean definitions / configuration
https://gist.github.com/4040646
Parallel Ingestion ActiveMQ Manager
https://gist.github.com/4fc5669d41f25072d2f4
Broker Factory (see bean definition in ActiveMQ bean definitions)
https://gist.github.com/8ad9cf6ace9245c63f41
> 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-kyle.xml, 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
