[ https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493324#comment-13493324
]
Kyle Miller commented on AMQ-4122:
----------------------------------
We are seeing a similar issue. After debugging, I've found some odd behavior.
When the LockableServiceSupport class gets a "false" back from the LeaseDatabaseBaseLocker.keepAlive()
method, it calls LockableServiceSupport.stopBroker().
On line 132 of LockableServiceSupport:
LOG.info(brokerService.getBrokerName() + ", no longer able to keep the exclusive lock so giving
up being a master");
This fails for me with a NullPointerException, which kills the thread, but does not stop the
broker.
It turns out, there is an org.apache.activemq.broker.BrokerService variable (brokerService)
that is null. However, there is also a org.apache.activemq.xbean.XBeanBrokerService variable
(brokerService) that is not null. This is odd.
I'm guessing that I have a problem with my configuration. I will be posting mine as well.
> 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
|