[jira] [Commented] (AMQ-4831) Average message size attribute on broker mbean should not have decimals
[ https://issues.apache.org/jira/browse/AMQ-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923613#comment-13923613 ] Arthur Naseef commented on AMQ-4831: Typically, I like to see formatting handled entirely on the UI front, and that applies here. Also, the display looks acceptable to me. With that said, tracking average message size as a real number seems excessive. Even for very small message sizes (say 1-10 bytes), it doesn't seem to add much value (would you monitor and have a threshold at 1.5 bytes?). So, changing it to an integer or long seems viable. > Average message size attribute on broker mbean should not have decimals > --- > > Key: AMQ-4831 > URL: https://issues.apache.org/jira/browse/AMQ-4831 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker, JMX >Affects Versions: 5.9.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 5.10.0 > > Attachments: avg-size.png > > > This doesn't look very nice when looking from a jmx console such as hawtio. > See screenshot, and notice the many decimals the average message size > attribute has. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-4831) Average message size attribute on broker mbean should not have decimals
[ https://issues.apache.org/jira/browse/AMQ-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923483#comment-13923483 ] Hadrian Zbarcea commented on AMQ-4831: -- I think the current implementation is ok. I agree that on the presentation part it would be the job of the console to display something appropriate and aesthetically pleasing. The mbean should supply an accurate value as it may be used by machines as well, not only human consumption. As far as jconsole goes, it presents the raw data it gets as expected. I'd suggest closing this as a won't fix, or move it to need-review. wdyt? > Average message size attribute on broker mbean should not have decimals > --- > > Key: AMQ-4831 > URL: https://issues.apache.org/jira/browse/AMQ-4831 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker, JMX >Affects Versions: 5.9.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 5.10.0 > > Attachments: avg-size.png > > > This doesn't look very nice when looking from a jmx console such as hawtio. > See screenshot, and notice the many decimals the average message size > attribute has. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5088) db.data
[ https://issues.apache.org/jira/browse/AMQ-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923360#comment-13923360 ] Timothy Bish commented on AMQ-5088: --- Try testing against v5.9.0 or 5.10-SNAPSHOT. If you can create a unit test then there's something to look into, otherwise this issue is not able to be investigated and will be closed as incomplete. > db.data > --- > > Key: AMQ-5088 > URL: https://issues.apache.org/jira/browse/AMQ-5088 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.7.0 > Environment: jdk1.6, Linux >Reporter: Ravi Somepalli > > db.data file keeps increasing, we have activemq version 5.7.0 and we use > persistent queues. > Could you please look into this, find below the persister configuration > > > indexWriteBatchSize="1" > indexCacheSize="1000" checkpointInterval="5000" > enableIndexWriteAsync="true" > cleanupInterval="5000" > journalMaxFileLength="32mb" > enableJournalDiskSyncs="true" > checkForCorruptJournalFiles="true" /> > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5088) db.data
[ https://issues.apache.org/jira/browse/AMQ-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ravi Somepalli updated AMQ-5088: Description: db.data file keeps increasing, we have activemq version 5.7.0 and we use persistent queues. Could you please look into this, find below the persister configuration was: db.data file keeps increasing, we have activemq version 5.7.0 and we use persistent queues. Could you please look into this > db.data > --- > > Key: AMQ-5088 > URL: https://issues.apache.org/jira/browse/AMQ-5088 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.7.0 > Environment: jdk1.6, Linux >Reporter: Ravi Somepalli > > db.data file keeps increasing, we have activemq version 5.7.0 and we use > persistent queues. > Could you please look into this, find below the persister configuration > > > indexWriteBatchSize="1" > indexCacheSize="1000" checkpointInterval="5000" > enableIndexWriteAsync="true" > cleanupInterval="5000" > journalMaxFileLength="32mb" > enableJournalDiskSyncs="true" > checkForCorruptJournalFiles="true" /> > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5088) db.data
[ https://issues.apache.org/jira/browse/AMQ-5088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ravi Somepalli updated AMQ-5088: Affects Version/s: 5.7.0 > db.data > --- > > Key: AMQ-5088 > URL: https://issues.apache.org/jira/browse/AMQ-5088 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.7.0 > Environment: jdk1.6, Linux >Reporter: Ravi Somepalli > > db.data file keeps increasing, we have activemq version 5.7.0 and we use > persistent queues. > Could you please look into this -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5088) db.data
Ravi Somepalli created AMQ-5088: --- Summary: db.data Key: AMQ-5088 URL: https://issues.apache.org/jira/browse/AMQ-5088 Project: ActiveMQ Issue Type: Bug Environment: jdk1.6, Linux Reporter: Ravi Somepalli db.data file keeps increasing, we have activemq version 5.7.0 and we use persistent queues. Could you please look into this -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-3956) KahaDB pagefile (db.data) steady growth - BTreeIndex page leak
[ https://issues.apache.org/jira/browse/AMQ-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923323#comment-13923323 ] Ravi Somepalli commented on AMQ-3956: - We have 5.7.0 and use only persistent queues this issue is failing > KahaDB pagefile (db.data) steady growth - BTreeIndex page leak > -- > > Key: AMQ-3956 > URL: https://issues.apache.org/jira/browse/AMQ-3956 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.5.1, 5.6.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: index, kahadb, leak > Fix For: 5.7.0 > > > There is a page leak in the kahadb BTeeIndex that can result in the pagefile > (db.data) growing steadily. One use case that can reproduce is with durable > subs that repeatedly subscribe and unsubscribe with pending messages. > The problem can occur with particular usage of any btree index so the problem > is not confined to durable subs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-1541) Request for notification on failover in master/slave configuration
[ https://issues.apache.org/jira/browse/AMQ-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923274#comment-13923274 ] Gary Tully commented on AMQ-1541: - there is a test for this feature that fails - org.apache.activemq.broker.ft.QueueMasterSlaveTestSupport#testAdvisory looking at it - I can't see how a consumer is ever to receive this advisory b/c the transports are not created before the persistence adapter lock. Maybe this was only applicable to pure master slave. I thought a fix was to make the advisory retrospective, but then you would never not get an advisory. Any objections to removing it? > Request for notification on failover in master/slave configuration > -- > > Key: AMQ-1541 > URL: https://issues.apache.org/jira/browse/AMQ-1541 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Greg Frank >Assignee: Rob Davies >Priority: Minor > Fix For: 5.2.0 > > > There should be a way to register with a broker for notification upon it > gaining control as the new master in a master/slave configuration. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5087) RedeliveryPolicy redeliveryDelay is ignored if initialRedeliveryDelay is specified
[ https://issues.apache.org/jira/browse/AMQ-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-5087. - Resolution: Fixed fix in http://git-wip-us.apache.org/repos/asf/activemq/commit/33b88d34 initialRedeliveryDelay used for first attempt redeliveryDelay is now used for subsequent attempts > RedeliveryPolicy redeliveryDelay is ignored if initialRedeliveryDelay is > specified > --- > > Key: AMQ-5087 > URL: https://issues.apache.org/jira/browse/AMQ-5087 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, JMS client >Affects Versions: 5.9.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: initialRedeliveryDelay, redeliveryPolicy > Fix For: 5.10.0 > > > If we specify RedeliveryPolicy initialRedeliveryDelay and no exponent the > value is used for every redelivery attempt, not just the first. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5087) RedeliveryPolicy redeliveryDelay is ignored if initialRedeliveryDelay is specified
Gary Tully created AMQ-5087: --- Summary: RedeliveryPolicy redeliveryDelay is ignored if initialRedeliveryDelay is specified Key: AMQ-5087 URL: https://issues.apache.org/jira/browse/AMQ-5087 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client Affects Versions: 5.9.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 5.10.0 If we specify RedeliveryPolicy initialRedeliveryDelay and no exponent the value is used for every redelivery attempt, not just the first. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Issue Comment Deleted] (AMQ-4692) ActiveMQ broker does not publish last will messages
[
https://issues.apache.org/jira/browse/AMQ-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vatsal Shah updated AMQ-4692:
-
Comment: was deleted
(was: I can't find it's Last will & testament code.
Can someone please tell me where it is defined ?
I can try to make patch.
)
> ActiveMQ broker does not publish last will messages
> ---
>
> Key: AMQ-4692
> URL: https://issues.apache.org/jira/browse/AMQ-4692
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, MQTT
>Affects Versions: 5.8.0
> Environment: win7 64 OS.
>Reporter: greywolf
>
> When I run a MQTT client（paho or fuse）to connect ActiveMQ broker. if i
> terminate this client and can not receive LWT messages from broker.
> I changed broker from ActiveMQ to Mosquitto broker , everything is ok.
> below is my test class:
> package com.paho;
> import org.eclipse.paho.client.mqttv3.MqttCallback;
> import org.eclipse.paho.client.mqttv3.MqttClient;
> import org.eclipse.paho.client.mqttv3.MqttConnectOptions;
> import org.eclipse.paho.client.mqttv3.MqttDeliveryToken;
> import org.eclipse.paho.client.mqttv3.MqttException;
> import org.eclipse.paho.client.mqttv3.MqttMessage;
> import org.eclipse.paho.client.mqttv3.MqttSecurityException;
> import org.eclipse.paho.client.mqttv3.MqttTopic;
> public class Sub {
> private MqttClient mqttClient;
>
> public void subscriber(){
> try {
> mqttClient = new
> MqttClient("tcp://192.168.100.80:1883", MqttClient.generateClientId());
>
> MqttConnectOptions connectOptions = new
> MqttConnectOptions();
> //set will
> connectOptions.setWill(mqttClient.getTopic("lastwill"),
> new String("I am offline").getBytes(), 1, false);
> mqttClient.connect(connectOptions);
> mqttClient.setCallback(new MqttCallback(){
> public void connectionLost(Throwable
> paramThrowable) {
> System.out.println("Connection Exist.
> \nCause: " + paramThrowable);
> while(true){
> try {
> Thread.sleep(2);
>
> if(!mqttClient.isConnected()){
> subscriber();
> }
> } catch (InterruptedException
> e) {
> e.printStackTrace();
> }
> }
> }
> public void messageArrived(MqttTopic
> paramMqttTopic,
> MqttMessage paramMqttMessage)
> throws Exception {
> System.out.println("Message arrived
> From The Topic:\t"+paramMqttTopic.toString() +" \nMessage: " +
> paramMqttMessage.toString());
> }
> public void deliveryComplete(
> MqttDeliveryToken
> paramMqttDeliveryToken) {
> }
>
> });
>
> mqttClient.subscribe("durable",1);
> //mqttClient.subscribe("durable1",1);
>
> } catch (MqttException e) {
> e.printStackTrace();
> }
> }
>
> /**
>* @param args
>*/
> public static void main(String[] args) {
> Sub sub = new Sub();
> sub.subscriber();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (AMQ-5086) vm transport create=false&waitForStart race condition
Christian Mamen created AMQ-5086:
Summary: vm transport create=false&waitForStart race condition
Key: AMQ-5086
URL: https://issues.apache.org/jira/browse/AMQ-5086
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.7.0
Reporter: Christian Mamen
Experience this bug on 5.7.0, I think this is the same on the trunk
using vm transport for a client to connect to an embedded broker, in a
multithreaded application, I'm experiencing a an error (sometimes) which
appears to be a race condition at startup.
Im using create=false and waitForStart to create a connectionFactory for a
client connection
vm://ApplicationName?create=false&waitForStart=12
The broker service is started in a seperate thread
the client connection is started first. but surprisingly it tries start the
brokers transport connector. An apparent glitch follows when the broker service
stops and re-start the transport.
{noformat}
2014-03-05 11:07:57,626 [ClientConnection_thread] INFO
org.apache.activemq.broker.TransportConnector - Connector vm://ApplicationName
Started
[...]
2014-03-05 11:08:07,009 [Main_thread] INFO
org.apache.activemq.broker.TransportConnector - Connector vm://ApplicationName
Stopped
2014-03-05 11:08:07,011 [Main_thread] INFO
org.apache.activemq.broker.TransportConnector - Connector vm://ApplicationName
Started
{noformat}
I look into the activemq source and saw this:
BrokerService.class
{code}
public void start() throws Exception {
[...]
// in jvm master slave, lets not publish over existing broker till we get
the lock
final BrokerRegistry brokerRegistry = BrokerRegistry.getInstance();
if (brokerRegistry.lookup(getBrokerName()) == null) {
brokerRegistry.bind(getBrokerName(), BrokerService.this);
}
startPersistenceAdapter(startAsync);
startBroker(startAsync);
brokerRegistry.bind(getBrokerName(), BrokerService.this);
{code}
VMTransportFactory.class
{code}
private BrokerService lookupBroker(final BrokerRegistry registry, final
String brokerName, int waitForStart) {
BrokerService broker = null;
synchronized(registry.getRegistryMutext()) {
broker = registry.lookup(brokerName);
if (broker == null && waitForStart > 0) {
final long expiry = System.currentTimeMillis() + waitForStart;
while (broker == null && expiry > System.currentTimeMillis()) {
long timeout = Math.max(0, expiry -
System.currentTimeMillis());
try {
LOG.debug("waiting for broker named: " + brokerName + "
to start");
registry.getRegistryMutext().wait(timeout);
} catch (InterruptedException ignored) {
}
broker = registry.lookup(brokerName);
}
}
}
return broker;
}
{code}
It appears that create=false and waitForStart only waits for the broker to be
added to the BrokerRegistry. However when the brokerService is starts, it seems
that the broker is added to the registry before it is started.
I believe some synchronization is missing make the VMTransportFactory wait for
the broker not only to be added to the registry, but also fully started.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-5043) Improve MQTT spec compatibility
[ https://issues.apache.org/jira/browse/AMQ-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5043: - Fix Version/s: (was: 5.10.0) 5.10.1 > Improve MQTT spec compatibility > --- > > Key: AMQ-5043 > URL: https://issues.apache.org/jira/browse/AMQ-5043 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 5.10.1 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: ActiveMQ 5.10 release date?
I upgraded camel to the 2.12.3 which includes the security upgrade. There are also various test fixes that came in the past days that stabilized the builds. I also enabled the CI builds on the ASF servers (both java6 and java7). I think the trunk is now stable and we can start closing down on the 5.10.0 and 5.9.1 releases. For 5.9.1 I believe the lazy consensus was on spin off a maintenance branch off of the 5.9.0 tag and only apply targeted fixes. I will prepare a list of the patches since 5.9.0 and my take on what should be merged. On 5.10.0 there are still some 45 issues open. Some of them depend on a qpid proton release. Not sure if we could get things going in the qpid community. If not we may have to move them to a 5.10.1. I will go to the list of issues and try to defer what's not urgent. I have the cycles to start release builds as soon as this weekend or early next week. Thoughts? Hadrian On Friday 28 February 2014 16:01:52 boday wrote: > yep, we need a 5.10 or even a 5.9.1 release to get this bug fixed soon: > > https://issues.apache.org/jira/browse/AMQ-4832 > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/ActiveMQ-5-10-release-date-tp4678366 > p4678425.html Sent from the ActiveMQ - Dev mailing list archive at > Nabble.com. >
[jira] [Updated] (AMQ-5004) Dispatching large messages over AMQP is very slow.
[ https://issues.apache.org/jira/browse/AMQ-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-5004: -- Fix Version/s: (was: 5.10.1) 5.10.0 > Dispatching large messages over AMQP is very slow. > -- > > Key: AMQ-5004 > URL: https://issues.apache.org/jira/browse/AMQ-5004 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP >Affects Versions: 5.9.0 >Reporter: Timothy Bish >Priority: Blocker > Fix For: 5.10.0 > > > When testing against the QPid JMS client we see that a producer sending large > messages 10mb+ is quite fast but a consumer takes exponentially longer to > receive the message. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4782) Remove old webconsole from ActiveMQ 5.10 onwards
[ https://issues.apache.org/jira/browse/AMQ-4782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-4782: - Fix Version/s: (was: 5.10.0) NEEDS_REVIEW > Remove old webconsole from ActiveMQ 5.10 onwards > > > Key: AMQ-4782 > URL: https://issues.apache.org/jira/browse/AMQ-4782 > Project: ActiveMQ > Issue Type: Task >Affects Versions: 5.10.0 >Reporter: Claus Ibsen >Priority: Minor > Labels: web-console > Fix For: NEEDS_REVIEW > > > The old aging web console is deprecated in ActiveMQ 5.9, and intended to be > removed from next release, eg 5.10. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5004) Dispatching large messages over AMQP is very slow.
[ https://issues.apache.org/jira/browse/AMQ-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea updated AMQ-5004: - Fix Version/s: (was: 5.10.0) 5.10.1 > Dispatching large messages over AMQP is very slow. > -- > > Key: AMQ-5004 > URL: https://issues.apache.org/jira/browse/AMQ-5004 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP >Affects Versions: 5.9.0 >Reporter: Timothy Bish >Priority: Blocker > Fix For: 5.10.1 > > > When testing against the QPid JMS client we see that a producer sending large > messages 10mb+ is quite fast but a consumer takes exponentially longer to > receive the message. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5030) Upgrade Camel to latest 2.12.x patch
[ https://issues.apache.org/jira/browse/AMQ-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hadrian Zbarcea resolved AMQ-5030. -- Resolution: Fixed > Upgrade Camel to latest 2.12.x patch > > > Key: AMQ-5030 > URL: https://issues.apache.org/jira/browse/AMQ-5030 > Project: ActiveMQ > Issue Type: Task > Components: activemq-camel >Reporter: Claus Ibsen >Assignee: Hadrian Zbarcea >Priority: Blocker > Fix For: 5.10.0 > > > We need to upgrade to latest Camel 2.12.3 release to pickup some very > important fixes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (AMQ-5085) Number Of Consumer Lost
[ https://issues.apache.org/jira/browse/AMQ-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-5085. - Resolution: Invalid Usage questions should be directed to the users mailing list. > Number Of Consumer Lost > --- > > Key: AMQ-5085 > URL: https://issues.apache.org/jira/browse/AMQ-5085 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Reporter: AYDIN > > Related to AMQ Broker. > I have one reader and one processor. There is only one queue between them. > During tests I often need to delete queue. I realized that after some time, > when i start reader, processor's consumer goes away and it doesnt consume any > message from queue. Can it be related to locking or something? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5085) Number Of Consumer Lost
AYDIN created AMQ-5085: -- Summary: Number Of Consumer Lost Key: AMQ-5085 URL: https://issues.apache.org/jira/browse/AMQ-5085 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: AYDIN Related to AMQ Broker. I have one reader and one processor. There is only one queue between them. During tests I often need to delete queue. I realized that after some time, when i start reader, processor's consumer goes away and it doesnt consume any message from queue. Can it be related to locking or something? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-4122) Lease Database Locker failover broken
[ https://issues.apache.org/jira/browse/AMQ-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] metatech updated AMQ-4122: -- Attachment: amq_dual_master_5.7_backport.patch For those using ServiceMix 4.5, the file "amq_dual_master_5.7_backport.patch" provides a backport for ActiveMQ 5.7. > 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: AMQ4122.patch, activemq-kyle.xml, activemq.xml, > activemq.xml, amq_dual_master_5.7_backport.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 was sent by Atlassian JIRA (v6.2#6252)
