[jira] [Created] (AMQ-5481) Trace logs in MQTT Protocol Converter

[AR (JIRA)]

AR created AMQ-5481:
---

 Summary: Trace logs in MQTT Protocol Converter
 Key: AMQ-5481
 URL: https://issues.apache.org/jira/browse/AMQ-5481
 Project: ActiveMQ
  Issue Type: Improvement
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
Priority: Minor


Adding trace messages in MQTT Protocol Converter for easier debugging.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5481) Trace logs in MQTT Protocol Converter

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5481:

Attachment: MQTTProtocolConverter.java.tracepatch

 Trace logs in MQTT Protocol Converter
 -

 Key: AMQ-5481
 URL: https://issues.apache.org/jira/browse/AMQ-5481
 Project: ActiveMQ
  Issue Type: Improvement
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
Priority: Minor
  Labels: MQTT
 Attachments: MQTTProtocolConverter.java.tracepatch


 Adding trace messages in MQTT Protocol Converter for easier debugging.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5473) Race condition caused by Linkstealing might make durable subs inactive

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5473:

Attachment: (was: linksteal_durablesub.patch)

 Race condition caused by Linkstealing might make durable subs inactive
 --

 Key: AMQ-5473
 URL: https://issues.apache.org/jira/browse/AMQ-5473
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.11.0
Reporter: AR

 Link Stealing creates a new connection and disconnects the old connection. 
 These operations are done concurrently.
 New connection triggers addConsumer() for active subscriptions and old 
 connection stop causes removeConsumer() for the same.
 Problems:
  * addConsumer() would throw exception that the sub is already active (if 
 remove did not happen before)
  * even if we go past the exception, it will not set the right (new) 
 connection context and consumer info the subs
  * removeConsumer() may remove subcription even if it had different 
 connection context (created by linkstealing)
 Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5473) Race condition caused by Linkstealing might make durable subs inactive

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5473:

Attachment: linksteal_durablesub.patch

patch updated.

 Race condition caused by Linkstealing might make durable subs inactive
 --

 Key: AMQ-5473
 URL: https://issues.apache.org/jira/browse/AMQ-5473
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.11.0
Reporter: AR
 Attachments: linksteal_durablesub.patch


 Link Stealing creates a new connection and disconnects the old connection. 
 These operations are done concurrently.
 New connection triggers addConsumer() for active subscriptions and old 
 connection stop causes removeConsumer() for the same.
 Problems:
  * addConsumer() would throw exception that the sub is already active (if 
 remove did not happen before)
  * even if we go past the exception, it will not set the right (new) 
 connection context and consumer info the subs
  * removeConsumer() may remove subcription even if it had different 
 connection context (created by linkstealing)
 Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5473) Race condition caused by Linkstealing might make durable subs inactive

[AR (JIRA)]

AR created AMQ-5473:
---

 Summary: Race condition caused by Linkstealing might make durable 
subs inactive
 Key: AMQ-5473
 URL: https://issues.apache.org/jira/browse/AMQ-5473
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.11.0
Reporter: AR


Link Stealing creates a new connection and disconnects the old connection. 
These operations are done concurrently.
New connection triggers addConsumer() for active subscriptions and old 
connection stop causes removeConsumer() for the same.

Problems:
 * addConsumer() would throw exception that the sub is already active (if 
remove did not happen before)
 * even if we go past the exception, it will not activate the subs
 * remove consumer may remove subcription even if it had different connection 
context (created by linkstealing)


Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5473) Race condition caused by Linkstealing might make durable subs inactive

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5473:

Attachment: linksteal_durablesub.patch

 Race condition caused by Linkstealing might make durable subs inactive
 --

 Key: AMQ-5473
 URL: https://issues.apache.org/jira/browse/AMQ-5473
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.11.0
Reporter: AR
 Attachments: linksteal_durablesub.patch


 Link Stealing creates a new connection and disconnects the old connection. 
 These operations are done concurrently.
 New connection triggers addConsumer() for active subscriptions and old 
 connection stop causes removeConsumer() for the same.
 Problems:
  * addConsumer() would throw exception that the sub is already active (if 
 remove did not happen before)
  * even if we go past the exception, it will not activate the subs
  * remove consumer may remove subcription even if it had different connection 
 context (created by linkstealing)
 Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5473) Race condition caused by Linkstealing might make durable subs inactive

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5473:

Description: 
Link Stealing creates a new connection and disconnects the old connection. 
These operations are done concurrently.
New connection triggers addConsumer() for active subscriptions and old 
connection stop causes removeConsumer() for the same.

Problems:
 * addConsumer() would throw exception that the sub is already active (if 
remove did not happen before)
 * even if we go past the exception, it will not set the right (new) connection 
context and consumer info the subs
 * remove consumer may remove subcription even if it had different connection 
context (created by linkstealing)


Patch attached.

  was:
Link Stealing creates a new connection and disconnects the old connection. 
These operations are done concurrently.
New connection triggers addConsumer() for active subscriptions and old 
connection stop causes removeConsumer() for the same.

Problems:
 * addConsumer() would throw exception that the sub is already active (if 
remove did not happen before)
 * even if we go past the exception, it will not activate the subs
 * remove consumer may remove subcription even if it had different connection 
context (created by linkstealing)


Patch attached.


 Race condition caused by Linkstealing might make durable subs inactive
 --

 Key: AMQ-5473
 URL: https://issues.apache.org/jira/browse/AMQ-5473
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.11.0
Reporter: AR
 Attachments: linksteal_durablesub.patch


 Link Stealing creates a new connection and disconnects the old connection. 
 These operations are done concurrently.
 New connection triggers addConsumer() for active subscriptions and old 
 connection stop causes removeConsumer() for the same.
 Problems:
  * addConsumer() would throw exception that the sub is already active (if 
 remove did not happen before)
  * even if we go past the exception, it will not set the right (new) 
 connection context and consumer info the subs
  * remove consumer may remove subcription even if it had different connection 
 context (created by linkstealing)
 Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5473) Race condition caused by Linkstealing might make durable subs inactive

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5473:

Description: 
Link Stealing creates a new connection and disconnects the old connection. 
These operations are done concurrently.
New connection triggers addConsumer() for active subscriptions and old 
connection stop causes removeConsumer() for the same.

Problems:
 * addConsumer() would throw exception that the sub is already active (if 
remove did not happen before)
 * even if we go past the exception, it will not set the right (new) connection 
context and consumer info the subs
 * removeConsumer() may remove subcription even if it had different connection 
context (created by linkstealing)


Patch attached.

  was:
Link Stealing creates a new connection and disconnects the old connection. 
These operations are done concurrently.
New connection triggers addConsumer() for active subscriptions and old 
connection stop causes removeConsumer() for the same.

Problems:
 * addConsumer() would throw exception that the sub is already active (if 
remove did not happen before)
 * even if we go past the exception, it will not set the right (new) connection 
context and consumer info the subs
 * remove consumer may remove subcription even if it had different connection 
context (created by linkstealing)


Patch attached.


 Race condition caused by Linkstealing might make durable subs inactive
 --

 Key: AMQ-5473
 URL: https://issues.apache.org/jira/browse/AMQ-5473
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.11.0
Reporter: AR
 Attachments: linksteal_durablesub.patch


 Link Stealing creates a new connection and disconnects the old connection. 
 These operations are done concurrently.
 New connection triggers addConsumer() for active subscriptions and old 
 connection stop causes removeConsumer() for the same.
 Problems:
  * addConsumer() would throw exception that the sub is already active (if 
 remove did not happen before)
  * even if we go past the exception, it will not set the right (new) 
 connection context and consumer info the subs
  * removeConsumer() may remove subcription even if it had different 
 connection context (created by linkstealing)
 Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5428) Durable Subscriptions are not being setup while link stealing is happening

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233282#comment-14233282
 ] 

AR commented on AMQ-5428:
-

I think this is related to https://issues.apache.org/jira/browse/AMQ-5473. Can 
you verify?

 Durable Subscriptions are not being setup while link stealing is happening
 --

 Key: AMQ-5428
 URL: https://issues.apache.org/jira/browse/AMQ-5428
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
 Environment: Activemq 5.11-SNAPSHOT with leveldb and linkstealing 
 enabled.
Reporter: Netlancer

 Intermittently, while an mqtt client is reconnecting, the durable 
 subscriptions are not setup as error is thrown mentioning subscription is 
 still active.
 the same can be reproduced by adding sleep into stopAsync method.
 {code:title=ManagedTransportConnection.java|borderStyle=solid}
 @Override
 public void stopAsync() {
 if (!isStopping()) {
 synchronized (this) {
 unregisterMBean(byClientIdName);
 unregisterMBean(byAddressName);
 byClientIdName = null;
 byAddressName = null;
 }
 }
 try {
 Thread.sleep(4000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 super.stopAsync();
 }
 {code}
 stacktrace:
 2014-11-10 08:07:06,632 | WARN  | Error subscribing to  TopicAAA | 
 org.apache.activemq.transport.mqtt.strategy.AbstractMQTTSubscriptionStrategy 
 | ActiveMQ NIO Worker 2
 javax.jms.JMSException: Durable consumer is in use for client: Producer and 
 subscriptionName: EXACTLY_ONCE:TopicAAA
   at 
 org.apache.activemq.broker.region.TopicRegion.addConsumer(TopicRegion.java:123)[activemq-broker-5.11-SNAPSHOT.jar:5.11-SNAPSHOT]
   at 
 org.apache.activemq.broker.region.RegionBroker.addConsumer(RegionBroker.java:427)[activemq-broker-5.11-SNAPSHOT.jar:5.11-SNAPSHOT]
   at 
 org.apache.activemq.broker.jmx.ManagedRegionBroker.addConsumer(ManagedRegionBroker.java:244)[activemq-broker-5.11-SNAPSHOT.jar:5.11-SNAPSHOT]
   at 
 org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:102)[activemq-broker-5.11-SNAPSHOT.jar:5.11-SNAPSHOT]
   at 
 org.apache.activemq.advisory.AdvisoryBroker.addConsumer(AdvisoryBroker.java:104)[activemq-broker-5.11-SNAPSHOT.jar:5.11-SNAPSHOT]
   at 
 org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:102)[activemq-broker-5.11-SNAPSHOT.jar:5.11-SNAPSHOT]
   at 
 org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:102)[activemq-broker-5.11-SNAPSHOT.jar:5.11-SNAPSHOT]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5382) MQTT messages published after unsubscribe on a durable topic are received

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197477#comment-14197477
 ] 

AR commented on AMQ-5382:
-

What requirements in MQTT are you referring to specifically that require 
retroactive subs? Pubs with retain=1 ?

 MQTT messages published after unsubscribe on a durable topic are received
 -

 Key: AMQ-5382
 URL: https://issues.apache.org/jira/browse/AMQ-5382
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
  Labels: MQTT

 Test procedure:
 Create a durable subscription to topic durableunsubtest with clientid 
 durableUnsub.
 Publish a message with client2 to topic durableunsubtest. Make sure 
 retain flag is not set.
 Verify that the message is received (confirming creation of durable 
 subscription).
 Unsubscribe from topic durableunsubtest from clientid durableUnsub. 
 Disconnect client.
 Publish another message with client2.  Make sure retain flag is not set.
 Connect durableUnsub and subscribe to the topic again.
 Verify that no messages are received.
 JUnit Test Case code:
 {noformat}
 /*
  * Test unsubscribe on a durable subscription topic
  */
 @Test(timeout = 60 * 1000)
 public void testDurableUnsubscribe() throws Exception {
   // Create connection1
 final String clientId = durableUnsub;
 MQTT mqtt1 = createMQTTConnection(clientId, false);
 mqtt1.setKeepAlive((short) 60);
 final BlockingConnection connection1 = mqtt1.blockingConnection();
 connection1.connect();
 
 // create a durable subscription for client durableUnsub
 final String TOPICNAME = durableunsubtest;
 final String payload = durable unsub test;
 Topic[] topic = { new Topic(TOPICNAME, QoS.AT_LEAST_ONCE) };
 connection1.subscribe(topic);
 // Create connection2 and publish a message on the topic
 MQTT mqtt2 = createMQTTConnection(null, true);
 mqtt2.setKeepAlive((short) 60);
 final BlockingConnection connection2 = mqtt2.blockingConnection();
 connection2.connect();
 connection2.publish(TOPICNAME, payload.getBytes(), QoS.EXACTLY_ONCE, 
 false);
 // Verify that the durable subscription was created by receiving the 
 message
 // on connection1
 Message message = connection1.receive(10, TimeUnit.SECONDS);
 assertNotNull(message);
 message.ack();
 assertEquals(Unexpected String received, payload, new 
 String(message.getPayload()));
 // Unsubscribe the topic on connection1
 connection1.unsubscribe(new String[]{TOPICNAME});
 // Disconnect connection1
 connection1.disconnect();
 
 // Publish another message on connection2 for the same topic
 MQTT mqtt2a = createMQTTConnection(null, true);
 mqtt2a.setKeepAlive((short) 60);
 final BlockingConnection connection2a = mqtt2a.blockingConnection();
 connection2a.connect();
 connection2a.publish(TOPICNAME, payload.getBytes(), QoS.EXACTLY_ONCE, 
 false);

 // Create connection3 with the same clientid durableUnsub
 // and subscribe to the topic
 MQTT mqtt3 = createMQTTConnection(clientId, false);
 mqtt3.setKeepAlive((short) 60);
 BlockingConnection connection3 = mqtt3.blockingConnection();
 connection3.connect();
 connection3.subscribe(topic);
 message = connection3.receive(10, TimeUnit.SECONDS);
 // Since we have unsubscribed before the publish, we should not 
 receive
 // any message (retain flag was also not set during publish)
 assertNull(message); 
 }
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5418) MQTT Subscriber is able to receive messages published after unsubscribe()

[AR (JIRA)]

AR created AMQ-5418:
---

 Summary: MQTT Subscriber is able to receive messages published 
after unsubscribe()
 Key: AMQ-5418
 URL: https://issues.apache.org/jira/browse/AMQ-5418
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR


* Client1 - Create durable subscription
* Client2 - Publish
* Client1 should receive published messages at this point
* Client1 unsubscribe
* Client2 Publish
* Client1 should not receive messages at this point
* Client1 disconnect
* Client2 Publish
* Client1 connect and subscribe to same topic
* Client1 should not receive any messages (fails)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5418) MQTT Subscriber is able to receive messages published after unsubscribe()

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5418:

Attachment: paho_unsub_durable.java

Test case (use in file PahoMQTTTest.java) attached

 MQTT Subscriber is able to receive messages published after unsubscribe()
 -

 Key: AMQ-5418
 URL: https://issues.apache.org/jira/browse/AMQ-5418
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
 Attachments: paho_unsub_durable.java


 * Client1 - Create durable subscription
 * Client2 - Publish
 * Client1 should receive published messages at this point
 * Client1 unsubscribe
 * Client2 Publish
 * Client1 should not receive messages at this point
 * Client1 disconnect
 * Client2 Publish
 * Client1 connect and subscribe to same topic
 * Client1 should not receive any messages (fails)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5396) Linkstealing causes deadlock when old client disconnects before link stealing adds the connection

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175667#comment-14175667
 ] 

AR commented on AMQ-5396:
-

Test case to reproduce this (with Mqtt Paho client lib):

* In the broker source, in 
activemq-broker/src/main/java/org/apache/activemq/broker/region/RegionBroker.java
 add sleep between the 2 lines in function addConnection() as shown below:
{noformat}
TransportConnection transportConnection = 
(TransportConnection) connection;
 Thread.sleep(3);
 transportConnection.stopAsync();
{noformat}

* Run the broker
* Run the following test case:
{noformat}
@Test
public void testLinkStealingDeadlock2() throws MqttException, 
InterruptedException
{
MqttClient client1 = new MqttClient(tcp://localhost:1883, client1);

client1.connect();

Thread thread = new Thread(new Runnable() {
@Override
public void run() {
try {
System.out.println(Connecting client 2);
MqttClient client2 = new MqttClient(tcp://localhost:1883, 
client1); // should be same client id
client2.connect();
System.out.println(Done connecting client2);
} catch (MqttException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
thread.start(); 
Thread.sleep(2000);
System.out.println(Disconnecting client1...);
client1.disconnect();

System.out.println(Connecting client3...);
MqttClient client3 = new MqttClient(tcp://localhost:1883, client3);
client3.connect();

System.out.println(Client3 connected);

client3.disconnect();


Thread.sleep(120*1000);
Assert.assertTrue(true);
}
{noformat}

* Run jstack on the JVM


 Linkstealing causes deadlock when old client disconnects before link stealing 
 adds the connection
 -

 Key: AMQ-5396
 URL: https://issues.apache.org/jira/browse/AMQ-5396
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.11.0
Reporter: Sai
 Attachments: jstack.txt, linkstealing-deadlock.patch


 During link stealing in progress if the old client(or connection) issues a 
 disconnect can cause a deadlock due the order in which the locks are obtained 
 on RegionBroker.addConnection and TransportConnection.processRemoveConneciton.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5390) MQTT pending durable subscriber messages are not delievered after broker restart

[AR (JIRA)]

AR created AMQ-5390:
---

 Summary: MQTT pending durable subscriber messages are not 
delievered after broker restart
 Key: AMQ-5390
 URL: https://issues.apache.org/jira/browse/AMQ-5390
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR


If there are pending messages to be delivered to a subscriber and if the broker 
is restarted at this point, the pending messages are not delivered to the 
subscriber when it connects after broker restart.

I modified existing test case testReceiveMessageSentWhileOffline() and added 
test case testReceiveMessageSentWhileOfflineAndBrokerRestart() shown below:
changes:
* use standalone broker as I was not sure if embedded broker persists messages 
on permanent store.
* manually need to restart when test prompts to restart broker

{noformat}
@Test(timeout = 60 * 1000)
public void testReceiveMessageSentWhileOfflineAndBrokerRestart() throws 
Exception {
final byte[] payload = new byte[1024 * 32];
for (int i = 0; i  payload.length; i++) {
payload[i] = '2';
}

int numberOfRuns = 100;
int messagesPerRun = 2;

final MQTT mqttPub = createMQTTConnection(MQTT-Pub-Client, true);
final MQTT mqttSub = createMQTTConnection(MQTT-Sub-Client, false);
mqttPub.setHost(tcp://localhost:1883);
mqttSub.setHost(tcp://localhost:1883);

final BlockingConnection connectionPub = mqttPub.blockingConnection();
connectionPub.connect();

BlockingConnection connectionSub = mqttSub.blockingConnection();
connectionSub.connect();

Topic[] topics = { new Topic(TopicA, QoS.EXACTLY_ONCE) };
connectionSub.subscribe(topics);

for (int i = 0; i  messagesPerRun; ++i) {
connectionPub.publish(topics[0].name().toString(), payload, 
QoS.AT_LEAST_ONCE, false);
}

int received = 0;
for (int i = 0; i  messagesPerRun; ++i) {
Message message = connectionSub.receive(5, TimeUnit.SECONDS);
assertNotNull(message);
received++;
assertTrue(Arrays.equals(payload, message.getPayload()));
message.ack();
}
connectionSub.disconnect();

for (int j = 0; j  numberOfRuns; j++) {

for (int i = 0; i  messagesPerRun; ++i) {
connectionPub.publish(topics[0].name().toString(), payload, 
QoS.AT_LEAST_ONCE, false);
}

System.out.println(Restart broker here.);

Thread.sleep(3);

connectionSub = mqttSub.blockingConnection();
connectionSub.connect();
connectionSub.subscribe(topics);

for (int i = 0; i  messagesPerRun; ++i) {
Message message = connectionSub.receive(5, TimeUnit.SECONDS);
assertNotNull(message);
received++;
assertTrue(Arrays.equals(payload, message.getPayload()));
message.ack();
}
connectionSub.disconnect();
}
assertEquals(Should have received  + (messagesPerRun * (numberOfRuns 
+ 1)) +  messages, (messagesPerRun * (numberOfRuns + 1)), received);
}
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5385) MQTT Link Stealing fails when client reconnects more than once

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5385:

Description: 
Modified existing JUnit test case to *re-connect* with the same clientid a 
second time. Existing Test case tried once, which succeeded.
When client reconnects the second time (third connection attempt with the same 
clientid), link stealing does not happen.

Following is the modified test case.
{noformat}
@Test(timeout = 60 * 1000)
public void testDuplicateClientId() throws Exception {
// test link stealing enabled by default
final String clientId = duplicateClient;
MQTT mqtt = createMQTTConnection(clientId, false);
mqtt.setKeepAlive((short) 2);
final BlockingConnection connection = mqtt.blockingConnection();
connection.connect();
final String TOPICA = TopicA;
connection.publish(TOPICA, TOPICA.getBytes(), QoS.EXACTLY_ONCE, true);
 
MQTT mqtt1 = createMQTTConnection(clientId, false);
mqtt1.setKeepAlive((short) 2);
final BlockingConnection connection1 = mqtt1.blockingConnection();
connection1.connect();
 
assertTrue(Duplicate client disconnected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return connection1.isConnected();
}
}));
 
assertTrue(Old client still connected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return !connection.isConnected();
}
}));
 
MQTT mqtt2 = createMQTTConnection(clientId, false);
mqtt2.setKeepAlive((short) 2);
final BlockingConnection connection4 = mqtt2.blockingConnection();
connection4.connect();
 
assertTrue(Old client still connected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return !connection1.isConnected();
}
}));
   
assertTrue(Duplicate client disconnected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return connection4.isConnected();
}
}));
 
connection4.disconnect();
}
{noformat}

  was:
Modified existing JUnit test case to connect with the same clientid more than 
once. Existing Test case tried once, which succeeded.
When client reconnects the second time (third connection attempt with the same 
clientid), link stealing does not happen.

Following is the modified test case.
{noformat}
@Test(timeout = 60 * 1000)
public void testDuplicateClientId() throws Exception {
// test link stealing enabled by default
final String clientId = duplicateClient;
MQTT mqtt = createMQTTConnection(clientId, false);
mqtt.setKeepAlive((short) 2);
final BlockingConnection connection = mqtt.blockingConnection();
connection.connect();
final String TOPICA = TopicA;
connection.publish(TOPICA, TOPICA.getBytes(), QoS.EXACTLY_ONCE, true);
 
MQTT mqtt1 = createMQTTConnection(clientId, false);
mqtt1.setKeepAlive((short) 2);
final BlockingConnection connection1 = mqtt1.blockingConnection();
connection1.connect();
 
assertTrue(Duplicate client disconnected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return connection1.isConnected();
}
}));
 
assertTrue(Old client still connected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return !connection.isConnected();
}
}));
 
MQTT mqtt2 = createMQTTConnection(clientId, false);
mqtt2.setKeepAlive((short) 2);
final BlockingConnection connection4 = mqtt2.blockingConnection();
connection4.connect();
 
assertTrue(Old client still connected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return !connection1.isConnected();
}
}));
   
assertTrue(Duplicate client disconnected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return connection4.isConnected();
}
}));
 
connection4.disconnect();
}
{noformat}


 MQTT Link Stealing fails when client reconnects more than once
 --

 Key: AMQ-5385
 URL: https://issues.apache.org/jira/browse/AMQ-5385
 Project: ActiveMQ
 

[jira] [Updated] (AMQ-5385) MQTT Link Stealing fails when client reconnects more than once

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5385:

Attachment: RegionBroker.java.LinkStealing.patch

Patch for the LinkStealing not working for second or more reconnects issue.

 MQTT Link Stealing fails when client reconnects more than once
 --

 Key: AMQ-5385
 URL: https://issues.apache.org/jira/browse/AMQ-5385
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
 Attachments: RegionBroker.java.LinkStealing.patch


 Modified existing JUnit test case to *re-connect* with the same clientid a 
 second time. Existing Test case tried once, which succeeded.
 When client reconnects the second time (third connection attempt with the 
 same clientid), link stealing does not happen.
 Following is the modified test case.
 {noformat}
 @Test(timeout = 60 * 1000)
 public void testDuplicateClientId() throws Exception {
 // test link stealing enabled by default
 final String clientId = duplicateClient;
 MQTT mqtt = createMQTTConnection(clientId, false);
 mqtt.setKeepAlive((short) 2);
 final BlockingConnection connection = mqtt.blockingConnection();
 connection.connect();
 final String TOPICA = TopicA;
 connection.publish(TOPICA, TOPICA.getBytes(), QoS.EXACTLY_ONCE, true);
  
 MQTT mqtt1 = createMQTTConnection(clientId, false);
 mqtt1.setKeepAlive((short) 2);
 final BlockingConnection connection1 = mqtt1.blockingConnection();
 connection1.connect();
  
 assertTrue(Duplicate client disconnected, Wait.waitFor(new 
 Wait.Condition() {
 @Override
 public boolean isSatisified() throws Exception {
 return connection1.isConnected();
 }
 }));
  
 assertTrue(Old client still connected, Wait.waitFor(new 
 Wait.Condition() {
 @Override
 public boolean isSatisified() throws Exception {
 return !connection.isConnected();
 }
 }));
  
 MQTT mqtt2 = createMQTTConnection(clientId, false);
 mqtt2.setKeepAlive((short) 2);
 final BlockingConnection connection4 = mqtt2.blockingConnection();
 connection4.connect();
  
 assertTrue(Old client still connected, Wait.waitFor(new 
 Wait.Condition() {
 @Override
 public boolean isSatisified() throws Exception {
 return !connection1.isConnected();
 }
 }));

 assertTrue(Duplicate client disconnected, Wait.waitFor(new 
 Wait.Condition() {
 @Override
 public boolean isSatisified() throws Exception {
 return connection4.isConnected();
 }
 }));
  
 connection4.disconnect();
 }
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5385) Link Stealing fails when client reconnects more than once

[AR (JIRA)]

AR created AMQ-5385:
---

 Summary: Link Stealing fails when client reconnects more than once
 Key: AMQ-5385
 URL: https://issues.apache.org/jira/browse/AMQ-5385
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR


Modified existing JUnit test case to connect with the same clientid more than 
once. Existing Test case tried once, which succeeded.
When client reconnects the second time (third connection attempt with the same 
clientid), link stealing does not happen.

Following is the modified test case.
{noformat}
@Test(timeout = 60 * 1000)
public void testDuplicateClientId() throws Exception {
// test link stealing enabled by default
final String clientId = duplicateClient;
MQTT mqtt = createMQTTConnection(clientId, false);
mqtt.setKeepAlive((short) 2);
final BlockingConnection connection = mqtt.blockingConnection();
connection.connect();
final String TOPICA = TopicA;
connection.publish(TOPICA, TOPICA.getBytes(), QoS.EXACTLY_ONCE, true);
 
MQTT mqtt1 = createMQTTConnection(clientId, false);
mqtt1.setKeepAlive((short) 2);
final BlockingConnection connection1 = mqtt1.blockingConnection();
connection1.connect();
 
assertTrue(Duplicate client disconnected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return connection1.isConnected();
}
}));
 
assertTrue(Old client still connected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return !connection.isConnected();
}
}));
 
MQTT mqtt2 = createMQTTConnection(clientId, false);
mqtt2.setKeepAlive((short) 2);
final BlockingConnection connection4 = mqtt2.blockingConnection();
connection4.connect();
 
assertTrue(Old client still connected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return !connection1.isConnected();
}
}));
   
assertTrue(Duplicate client disconnected, Wait.waitFor(new 
Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
return connection4.isConnected();
}
}));
 
connection4.disconnect();
}
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5382) MQTT messages published after unsubscribe on a durable topic are received

[AR (JIRA)]

AR created AMQ-5382:
---

 Summary: MQTT messages published after unsubscribe on a durable 
topic are received
 Key: AMQ-5382
 URL: https://issues.apache.org/jira/browse/AMQ-5382
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR




Test procedure:

Create a durable subscription to topic durableunsubtest with clientid 
durableUnsub.
Publish a message with client2 to topic durableunsubtest.
Verify that the message is received (confirming creation of durable 
subscription).
Unsubscribe from topic durableunsubtest from clientid durableUnsub. 
Disconnect client.

Publish another message with client2.

Connect durableUnsub and subscribe to the topic again.

Verify that no messages are received.


JUnit Test Case code:
{noformat}
/*
 * Test unsubscribe on a durable subscription topic
 */
@Test(timeout = 60 * 1000)
public void testDurableUnsubscribe() throws Exception {

// Create connection1
final String clientId = durableUnsub;
MQTT mqtt1 = createMQTTConnection(clientId, false);
mqtt1.setKeepAlive((short) 60);
final BlockingConnection connection1 = mqtt1.blockingConnection();
connection1.connect();

// create a durable subscription for client durableUnsub
final String TOPICNAME = durableunsubtest;
final String payload = durable unsub test;
Topic[] topic = { new Topic(TOPICNAME, QoS.AT_LEAST_ONCE) };
connection1.subscribe(topic);

// Create connection2 and publish a message on the topic
MQTT mqtt2 = createMQTTConnection(null, true);
mqtt2.setKeepAlive((short) 60);
final BlockingConnection connection2 = mqtt2.blockingConnection();
connection2.connect();
connection2.publish(TOPICNAME, payload.getBytes(), QoS.EXACTLY_ONCE, 
false);

// Verify that the durable subscription was created by receiving the 
message
// on connection1
Message message = connection1.receive(10, TimeUnit.SECONDS);
assertNotNull(message);
message.ack();
assertEquals(Unexpected String received, payload, new 
String(message.getPayload()));

// Unsubscribe the topic on connection1
connection1.unsubscribe(new String[]{TOPICNAME});

// Disconnect connection1
connection1.disconnect();

// Publish another message on connection2 for the same topic
MQTT mqtt2a = createMQTTConnection(null, true);
mqtt2a.setKeepAlive((short) 60);
final BlockingConnection connection2a = mqtt2a.blockingConnection();
connection2a.connect();
connection2a.publish(TOPICNAME, payload.getBytes(), QoS.EXACTLY_ONCE, 
false);
   
// Create connection3 with the same clientid durableUnsub
// and subscribe to the topic
MQTT mqtt3 = createMQTTConnection(clientId, false);
mqtt3.setKeepAlive((short) 60);
BlockingConnection connection3 = mqtt3.blockingConnection();
connection3.connect();
connection3.subscribe(topic);
message = connection3.receive(10, TimeUnit.SECONDS);

// Since we have unsubscribed before the publish, we should not receive
// any message (retain flag was also not set during publish)
assertNull(message); 
}
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5382) MQTT messages published after unsubscribe on a durable topic are received

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5382:

Description: 
Test procedure:

Create a durable subscription to topic durableunsubtest with clientid 
durableUnsub.
Publish a message with client2 to topic durableunsubtest. Make sure retain 
flag is not set.
Verify that the message is received (confirming creation of durable 
subscription).
Unsubscribe from topic durableunsubtest from clientid durableUnsub. 
Disconnect client.

Publish another message with client2.  Make sure retain flag is not set.

Connect durableUnsub and subscribe to the topic again.

Verify that no messages are received.


JUnit Test Case code:
{noformat}
/*
 * Test unsubscribe on a durable subscription topic
 */
@Test(timeout = 60 * 1000)
public void testDurableUnsubscribe() throws Exception {

// Create connection1
final String clientId = durableUnsub;
MQTT mqtt1 = createMQTTConnection(clientId, false);
mqtt1.setKeepAlive((short) 60);
final BlockingConnection connection1 = mqtt1.blockingConnection();
connection1.connect();

// create a durable subscription for client durableUnsub
final String TOPICNAME = durableunsubtest;
final String payload = durable unsub test;
Topic[] topic = { new Topic(TOPICNAME, QoS.AT_LEAST_ONCE) };
connection1.subscribe(topic);

// Create connection2 and publish a message on the topic
MQTT mqtt2 = createMQTTConnection(null, true);
mqtt2.setKeepAlive((short) 60);
final BlockingConnection connection2 = mqtt2.blockingConnection();
connection2.connect();
connection2.publish(TOPICNAME, payload.getBytes(), QoS.EXACTLY_ONCE, 
false);

// Verify that the durable subscription was created by receiving the 
message
// on connection1
Message message = connection1.receive(10, TimeUnit.SECONDS);
assertNotNull(message);
message.ack();
assertEquals(Unexpected String received, payload, new 
String(message.getPayload()));

// Unsubscribe the topic on connection1
connection1.unsubscribe(new String[]{TOPICNAME});

// Disconnect connection1
connection1.disconnect();

// Publish another message on connection2 for the same topic
MQTT mqtt2a = createMQTTConnection(null, true);
mqtt2a.setKeepAlive((short) 60);
final BlockingConnection connection2a = mqtt2a.blockingConnection();
connection2a.connect();
connection2a.publish(TOPICNAME, payload.getBytes(), QoS.EXACTLY_ONCE, 
false);
   
// Create connection3 with the same clientid durableUnsub
// and subscribe to the topic
MQTT mqtt3 = createMQTTConnection(clientId, false);
mqtt3.setKeepAlive((short) 60);
BlockingConnection connection3 = mqtt3.blockingConnection();
connection3.connect();
connection3.subscribe(topic);
message = connection3.receive(10, TimeUnit.SECONDS);

// Since we have unsubscribed before the publish, we should not receive
// any message (retain flag was also not set during publish)
assertNull(message); 
}
{noformat}

  was:


Test procedure:

Create a durable subscription to topic durableunsubtest with clientid 
durableUnsub.
Publish a message with client2 to topic durableunsubtest.
Verify that the message is received (confirming creation of durable 
subscription).
Unsubscribe from topic durableunsubtest from clientid durableUnsub. 
Disconnect client.

Publish another message with client2.

Connect durableUnsub and subscribe to the topic again.

Verify that no messages are received.


JUnit Test Case code:
{noformat}
/*
 * Test unsubscribe on a durable subscription topic
 */
@Test(timeout = 60 * 1000)
public void testDurableUnsubscribe() throws Exception {

// Create connection1
final String clientId = durableUnsub;
MQTT mqtt1 = createMQTTConnection(clientId, false);
mqtt1.setKeepAlive((short) 60);
final BlockingConnection connection1 = mqtt1.blockingConnection();
connection1.connect();

// create a durable subscription for client durableUnsub
final String TOPICNAME = durableunsubtest;
final String payload = durable unsub test;
Topic[] topic = { new Topic(TOPICNAME, QoS.AT_LEAST_ONCE) };
connection1.subscribe(topic);

// Create connection2 and publish a message on the topic
MQTT mqtt2 = createMQTTConnection(null, true);
mqtt2.setKeepAlive((short) 60);
final BlockingConnection connection2 = mqtt2.blockingConnection();
connection2.connect();
connection2.publish(TOPICNAME, payload.getBytes(), QoS.EXACTLY_ONCE, 
false);

// Verify that the durable subscription was created by receiving the 

[jira] [Commented] (AMQ-5365) MQTT topic name in received message is wrong in network of brokers scenario

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143421#comment-14143421
 ] 

AR commented on AMQ-5365:
-

Broker1:
 networkConnector uri=static:(tcp://localhost:62002)/
 transportConnector uri=tcp://localhost:62001/

Broker2:
 networkConnector uri=static:(tcp://localhost:62001)/
 transportConnector uri=tcp://localhost:62002/

 MQTT topic name in received message is wrong in network of brokers scenario
 ---

 Key: AMQ-5365
 URL: https://issues.apache.org/jira/browse/AMQ-5365
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
  Labels: mqtt, networkofbrokers

 Setup:
 Broker1 and Broker2 are networked using a duplex connection.
 Broker1 -- Broker2
 Transport connector of Broker1:
 -
 transportConnector 
 name=mqtturi=mqtt://0.0.0.0:1883?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600amp;transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/
 Transport connector of Broker2:
 -
 transportConnector 
 name=mqtturi=mqtt://0.0.0.0:2883?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600amp;transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/
 Problem:
 In a network of brokers scenario with MQTT clients, sometimes the topic that 
 is reported (to the clients) when the message is received has extra 
 information prefixed to what the consumer subscribed to. For example, if the 
 consumer received a message on topic dup/msg/test, it is received as:
 Consumer/duptestsub:AT_LEAST_ONCE/VirtualTopic/dup/msg/tes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5365) MQTT topic name in received message is wrong in network of brokers scenario

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5365:

Description: 
Setup:
Broker1 and Broker2 are networked using a duplex connection.
Broker1 -- Broker2

Transport connector of Broker1:
-
transportConnector 
name=mqtturi=mqtt://0.0.0.0:1883?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600amp;transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/


Transport connector of Broker2:
-
transportConnector 
name=mqtturi=mqtt://0.0.0.0:2883?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600amp;transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/

Problem:
In a network of brokers scenario with MQTT clients, sometimes the topic that is 
reported (to the clients) when the message is received has extra information 
prefixed to what the consumer subscribed to. For example, if the consumer 
received a message on topic dup/msg/test, it is received as:

Consumer/duptestsub:AT_LEAST_ONCE/VirtualTopic/dup/msg/tes

  was:
Sometimes the topic that is reported when the message is received has extra 
information prefixed to what the consumer subscribed to. For example, if the 
consumer received a message on topic dup/msg/test, it is received as:

Consumer/duptestsub:AT_LEAST_ONCE/VirtualTopic/dup/msg/tes


 MQTT topic name in received message is wrong in network of brokers scenario
 ---

 Key: AMQ-5365
 URL: https://issues.apache.org/jira/browse/AMQ-5365
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
  Labels: mqtt, networkofbrokers

 Setup:
 Broker1 and Broker2 are networked using a duplex connection.
 Broker1 -- Broker2
 Transport connector of Broker1:
 -
 transportConnector 
 name=mqtturi=mqtt://0.0.0.0:1883?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600amp;transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/
 Transport connector of Broker2:
 -
 transportConnector 
 name=mqtturi=mqtt://0.0.0.0:2883?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600amp;transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/
 Problem:
 In a network of brokers scenario with MQTT clients, sometimes the topic that 
 is reported (to the clients) when the message is received has extra 
 information prefixed to what the consumer subscribed to. For example, if the 
 consumer received a message on topic dup/msg/test, it is received as:
 Consumer/duptestsub:AT_LEAST_ONCE/VirtualTopic/dup/msg/tes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5364) MQTT Unsubscribe does not work as intended in network of brokers scenario

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5364:

Attachment: ActivemqNbTests.tar.gz

 MQTT Unsubscribe does not work as intended in network of brokers scenario
 -

 Key: AMQ-5364
 URL: https://issues.apache.org/jira/browse/AMQ-5364
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
  Labels: mqtt, networkofbrokers
 Attachments: ActivemqNbTests.tar.gz


 I’m trying to make sure that if an unsubscribe() is done for an existing 
 durable topic in any of the brokers, it takes effect in all the brokers (I.e) 
 no further messages published to that topic (in any of the brokers) should be 
 received by the client that unsubscribed (when it connects at a later time 
 after publish).
 I’ve explained my test cases below and also I’ve attached my test code. The 
 test numbers (from the list below) that are failing are 2, 4, 6, 7, 8, 9.
 /*  
  * Test if unsubscribe() works as intended in a network of brokers (two) 
 scenario
  * 
  * Setup:
  * Broker1 and Broker2 are networked.
  *  Broker1(B1)-   Broker2(B2)
  * 
  * General flow:
  * 1. Clear any previous durable subs in B1 and B2 (use clean_session = true)
  * 2. Create durable subscription by connecting to B1
  * 3. Publish message in B1
  * 4. Confirm that the durable subscription was created by connecting to B1 
 and receiving the message
  * 5. Unsubscribe in B1 or B2 or both
  * 6. Publish message in B1 or B2 or both
  * 7. Connect to B1 (and B2) and make sure message is NOT received
  * 
  * In steps 5 (Unsub) and 6 (Pub), we can perform the steps in B1 or B2 or 
 both. This gives rise to the following test cases
  *  UnsubB1 UnsubB2 PubB1   PubB2
  * -
  * 1.   false   truefalse   true
  * 2.   truefalse   false   true
  * 3.   truetruefalse   true
  * 4.   false   truetruefalse
  * 5.   truefalse   truefalse
  * 6.   truetruetruefalse
  * 7.   false   truetruetrue
  * 8.   truefalse   truetrue
  * 9.   truetruetruetrue
  */



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5364) MQTT Unsubscribe does not work as intended in network of brokers scenario

[AR (JIRA)]

AR created AMQ-5364:
---

 Summary: MQTT Unsubscribe does not work as intended in network of 
brokers scenario
 Key: AMQ-5364
 URL: https://issues.apache.org/jira/browse/AMQ-5364
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
 Attachments: ActivemqNbTests.tar.gz

I’m trying to make sure that if an unsubscribe() is done for an existing 
durable topic in any of the brokers, it takes effect in all the brokers (I.e) 
no further messages published to that topic (in any of the brokers) should be 
received by the client that unsubscribed (when it connects at a later time 
after publish).

I’ve explained my test cases below and also I’ve attached my test code. The 
test numbers (from the list below) that are failing are 2, 4, 6, 7, 8, 9.

/*  
 * Test if unsubscribe() works as intended in a network of brokers (two) 
scenario
 * 
 * Setup:
 * Broker1 and Broker2 are networked.
 *  Broker1(B1)-   Broker2(B2)
 * 
 * General flow:
 * 1. Clear any previous durable subs in B1 and B2 (use clean_session = true)
 * 2. Create durable subscription by connecting to B1
 * 3. Publish message in B1
 * 4. Confirm that the durable subscription was created by connecting to B1 and 
receiving the message
 * 5. Unsubscribe in B1 or B2 or both
 * 6. Publish message in B1 or B2 or both
 * 7. Connect to B1 (and B2) and make sure message is NOT received
 * 
 * In steps 5 (Unsub) and 6 (Pub), we can perform the steps in B1 or B2 or 
both. This gives rise to the following test cases
 *  UnsubB1 UnsubB2 PubB1   PubB2
 * -
 * 1.   false   truefalse   true
 * 2.   truefalse   false   true
 * 3.   truetruefalse   true
 * 4.   false   truetruefalse
 * 5.   truefalse   truefalse
 * 6.   truetruetruefalse
 * 7.   false   truetruetrue
 * 8.   truefalse   truetrue
 * 9.   truetruetruetrue
 */




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5365) MQTT topic name in received message is wrong in network of brokers scenario

[AR (JIRA)]

AR created AMQ-5365:
---

 Summary: MQTT topic name in received message is wrong in network 
of brokers scenario
 Key: AMQ-5365
 URL: https://issues.apache.org/jira/browse/AMQ-5365
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR


Sometimes the topic that is reported when the message is received has extra 
information prefixed to what the consumer subscribed to. For example, if the 
consumer received a message on topic dup/msg/test, it is received as:

Consumer/duptestsub:AT_LEAST_ONCE/VirtualTopic/dup/msg/tes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5364) MQTT Unsubscribe does not work as intended in network of brokers scenario

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5364:

Description: 
I’m trying to make sure that if an unsubscribe() is done for an existing 
durable topic in any of the brokers, it takes effect in all the brokers (I.e) 
no further messages published to that topic (in any of the brokers) should be 
received by the client that unsubscribed (when it connects at a later time 
after publish).

I’ve explained my test cases below and also I’ve attached my test code. The 
test numbers (from the list below) that are failing are 2, 4, 6, 7, 8, 9.

/*  
 * Test if unsubscribe() works as intended in a network of brokers (two) 
scenario
 * 
 * Setup:
 * Broker1 and Broker2 are networked. 
 *  Broker1(B1)-   Broker2(B2)
 * 
 * B1 is running MQTT transport on 1883 and B2 on 2883 on the same machine. 
They have a duplex network connector between them. The MQTT transport connector 
uses the transport.subscriptionStrategy option as shown below:
transportConnector 
name=mqtturi=mqtt://0.0.0.0:1883?maximumConnections=1000amp;wireFormat.maxFrameSize=104857600amp;transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/
 * 
 * General flow:
 * 1. Clear any previous durable subs in B1 and B2 (use clean_session = true)
 * 2. Create durable subscription by connecting to B1
 * 3. Publish message in B1
 * 4. Confirm that the durable subscription was created by connecting to B1 and 
receiving the message
 * 5. Unsubscribe in B1 or B2 or both
 * 6. Publish message in B1 or B2 or both
 * 7. Connect to B1 (and B2) and make sure message is NOT received
 * 
 * In steps 5 (Unsub) and 6 (Pub), we can perform the steps in B1 or B2 or 
both. This gives rise to the following test cases
 *  UnsubB1 UnsubB2 PubB1   PubB2
 * -
 * 1.   false   truefalse   true
 * 2.   truefalse   false   true
 * 3.   truetruefalse   true
 * 4.   false   truetruefalse
 * 5.   truefalse   truefalse
 * 6.   truetruetruefalse
 * 7.   false   truetruetrue
 * 8.   truefalse   truetrue
 * 9.   truetruetruetrue
 */


  was:
I’m trying to make sure that if an unsubscribe() is done for an existing 
durable topic in any of the brokers, it takes effect in all the brokers (I.e) 
no further messages published to that topic (in any of the brokers) should be 
received by the client that unsubscribed (when it connects at a later time 
after publish).

I’ve explained my test cases below and also I’ve attached my test code. The 
test numbers (from the list below) that are failing are 2, 4, 6, 7, 8, 9.

/*  
 * Test if unsubscribe() works as intended in a network of brokers (two) 
scenario
 * 
 * Setup:
 * Broker1 and Broker2 are networked.
 *  Broker1(B1)-   Broker2(B2)
 * 
 * General flow:
 * 1. Clear any previous durable subs in B1 and B2 (use clean_session = true)
 * 2. Create durable subscription by connecting to B1
 * 3. Publish message in B1
 * 4. Confirm that the durable subscription was created by connecting to B1 and 
receiving the message
 * 5. Unsubscribe in B1 or B2 or both
 * 6. Publish message in B1 or B2 or both
 * 7. Connect to B1 (and B2) and make sure message is NOT received
 * 
 * In steps 5 (Unsub) and 6 (Pub), we can perform the steps in B1 or B2 or 
both. This gives rise to the following test cases
 *  UnsubB1 UnsubB2 PubB1   PubB2
 * -
 * 1.   false   truefalse   true
 * 2.   truefalse   false   true
 * 3.   truetruefalse   true
 * 4.   false   truetruefalse
 * 5.   truefalse   truefalse
 * 6.   truetruetruefalse
 * 7.   false   truetruetrue
 * 8.   truefalse   truetrue
 * 9.   truetruetruetrue
 */



 MQTT Unsubscribe does not work as intended in network of brokers scenario
 -

 Key: AMQ-5364
 URL: https://issues.apache.org/jira/browse/AMQ-5364
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.11.0
Reporter: AR
  Labels: mqtt, networkofbrokers
 Attachments: ActivemqNbTests.tar.gz


 I’m trying to make sure that if an unsubscribe() is 

[jira] [Commented] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135657#comment-14135657
 ] 

AR commented on AMQ-5358:
-

I don't think the spec is wrong. I meant that the MQTT implementation in 
ActiveMQ does not conform to the spec in this regard.

 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR
 Attachments: MqttDurableSubTest.java


 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Junit test code attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

AR created AMQ-5358:
---

 Summary: MQTT Durable subscription broken in 5.10 and 5.11
 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR


Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
Test case:
Run default broker.

. Connect client1 with clean_session=true.
. Subscribe to topic paho/test
. Disconnect client1
. Connect client1 with clean_session=false
. Subscribe to topic paho/test
. Disconnect client1

. Connect client2
. Publish message hello world to topic paho/test
. Disconnect client2

. Connect client1 with clean_session=false
. Subscribe to topic paho/test
. Verify that the message is received.


Here is the Junit test code:
--
package com.mytests.activemqtests;

import java.util.Date;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;
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.MqttException;
import org.eclipse.paho.client.mqttv3.MqttMessage;
import org.junit.Test;

import junit.framework.TestCase;


public class MqttDurableSubTest extends TestCase implements MqttCallback {

final static String BROKER1_URL = tcp://localhost:1883;

final static int MQTT_QOS_ATMOSTONCE = 0;
final static int MQTT_QOS_ATLEASTONCE = 1;
final static int MQTT_QOS_EXACTLYONCE = 2;

private boolean mMessageReceived = false;
private CountDownLatch mLatch;

public MqttDurableSubTest(String name) {
super(name);
}

protected void setUp() throws Exception {
super.setUp();
}

protected void tearDown() throws Exception {
super.tearDown();
}

@Test
public void testDuplicateMsg() throws Exception {

MqttConnectOptions client1ConnOpt = new MqttConnectOptions();
MqttClient client1 = new MqttClient(BROKER1_URL, client1);

client1ConnOpt.setCleanSession(true);
client1.connect();
System.out.println(Client1 Connected to  + BROKER1_URL);
client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);
Thread.sleep(2000);
client1.disconnect();
System.out.println(Client1 completed cleansession=1 
subscription.);


client1ConnOpt.setCleanSession(false);
client1.setCallback(this);
client1.connect(client1ConnOpt);

System.out.println(Client1 Connected to  + BROKER1_URL);
client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);
Thread.sleep(2000);
client1.disconnect();
System.out.println(Client1 completed durable subscription.);

MqttConnectOptions client2ConnOpt = new MqttConnectOptions();
client1ConnOpt.setCleanSession(true);
MqttClient client2 = new MqttClient(BROKER1_URL, client2);
client2.setCallback(this);
client2.connect(client2ConnOpt);
client2.publish(paho/test, hello world.getBytes(), 
MQTT_QOS_ATMOSTONCE, false);
System.out.println(Client2 published);
client2.disconnect();



client1ConnOpt.setCleanSession(false);
client1.setCallback(this);
client1.connect(client1ConnOpt);

System.out.println(Client1 Connected to  + BROKER1_URL);
client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);

mLatch = new CountDownLatch(1);
mLatch.await(10, TimeUnit.SECONDS);
assertEquals(Success!, true, mMessageReceived);
System.out.println(Done);
}

@Override
public void connectionLost(Throwable arg0) {
// TODO Auto-generated method stub

}

@Override
public void deliveryComplete(IMqttDeliveryToken arg0) {
// TODO Auto-generated method stub

}

@Override
public void messageArrived(String topic, MqttMessage message) throws 
Exception {

System.out.println(MQTT - messageArrived +topic+ , Message: 
[+message+] , ReceviedTime: [+ new Date() +] , QoS: [+message.getQos()+] 
, isDup: [+message.isDuplicate()+] );
if (message.toString().equals(hello world)) {

[jira] [Updated] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5358:

Attachment: MqttDurableSubTest.java

JUnit test case for MQTT Durable subscription test using MQTT Paho client 
library.

 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR
 Attachments: MqttDurableSubTest.java


 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Here is the Junit test code:
 --
 package com.mytests.activemqtests;
 import java.util.Date;
 import java.util.concurrent.CountDownLatch;
 import java.util.concurrent.TimeUnit;
 import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;
 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.MqttException;
 import org.eclipse.paho.client.mqttv3.MqttMessage;
 import org.junit.Test;
 import junit.framework.TestCase;
 public class MqttDurableSubTest extends TestCase implements MqttCallback {
   final static String BROKER1_URL = tcp://localhost:1883;
   
   final static int MQTT_QOS_ATMOSTONCE = 0;
   final static int MQTT_QOS_ATLEASTONCE = 1;
   final static int MQTT_QOS_EXACTLYONCE = 2;
   
   private boolean mMessageReceived = false;
   private CountDownLatch mLatch;
   public MqttDurableSubTest(String name) {
   super(name);
   }
   protected void setUp() throws Exception {
   super.setUp();
   }
   protected void tearDown() throws Exception {
   super.tearDown();
   }
   @Test
   public void testDuplicateMsg() throws Exception {
   MqttConnectOptions client1ConnOpt = new MqttConnectOptions();
   MqttClient client1 = new MqttClient(BROKER1_URL, client1);
   
   client1ConnOpt.setCleanSession(true);
   client1.connect();
   System.out.println(Client1 Connected to  + BROKER1_URL);
   client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);
   Thread.sleep(2000);
   client1.disconnect();
   System.out.println(Client1 completed cleansession=1 
 subscription.);
   
   
   client1ConnOpt.setCleanSession(false);
   client1.setCallback(this);
   client1.connect(client1ConnOpt);
   System.out.println(Client1 Connected to  + BROKER1_URL);
   client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);
   Thread.sleep(2000);
   client1.disconnect();
   System.out.println(Client1 completed durable subscription.);
   
   MqttConnectOptions client2ConnOpt = new MqttConnectOptions();
   client1ConnOpt.setCleanSession(true);
   MqttClient client2 = new MqttClient(BROKER1_URL, client2);
   client2.setCallback(this);
   client2.connect(client2ConnOpt);
   client2.publish(paho/test, hello world.getBytes(), 
 MQTT_QOS_ATMOSTONCE, false);
   System.out.println(Client2 published);
   client2.disconnect();
   
   
   client1ConnOpt.setCleanSession(false);
   client1.setCallback(this);
   client1.connect(client1ConnOpt);
   System.out.println(Client1 Connected to  + BROKER1_URL);
   client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);
   
   mLatch = new CountDownLatch(1);
   mLatch.await(10, TimeUnit.SECONDS);
   assertEquals(Success!, true, mMessageReceived);
   System.out.println(Done);
   }
   @Override
   public void connectionLost(Throwable arg0) {
   // TODO Auto-generated method stub
   }
   @Override
   public void deliveryComplete(IMqttDeliveryToken arg0) {
   // TODO Auto-generated method stub
   }
   @Override
   public void messageArrived(String topic, MqttMessage message) throws 
 Exception 

[jira] [Updated] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5358:

Description: 
Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
Test case:
Run default broker.

. Connect client1 with clean_session=true.
. Subscribe to topic paho/test
. Disconnect client1
. Connect client1 with clean_session=false
. Subscribe to topic paho/test
. Disconnect client1

. Connect client2
. Publish message hello world to topic paho/test
. Disconnect client2

. Connect client1 with clean_session=false
. Subscribe to topic paho/test
. Verify that the message is received.


Junit test code attached.

  was:
Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
Test case:
Run default broker.

. Connect client1 with clean_session=true.
. Subscribe to topic paho/test
. Disconnect client1
. Connect client1 with clean_session=false
. Subscribe to topic paho/test
. Disconnect client1

. Connect client2
. Publish message hello world to topic paho/test
. Disconnect client2

. Connect client1 with clean_session=false
. Subscribe to topic paho/test
. Verify that the message is received.


Here is the Junit test code:
--
package com.mytests.activemqtests;

import java.util.Date;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;
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.MqttException;
import org.eclipse.paho.client.mqttv3.MqttMessage;
import org.junit.Test;

import junit.framework.TestCase;


public class MqttDurableSubTest extends TestCase implements MqttCallback {

final static String BROKER1_URL = tcp://localhost:1883;

final static int MQTT_QOS_ATMOSTONCE = 0;
final static int MQTT_QOS_ATLEASTONCE = 1;
final static int MQTT_QOS_EXACTLYONCE = 2;

private boolean mMessageReceived = false;
private CountDownLatch mLatch;

public MqttDurableSubTest(String name) {
super(name);
}

protected void setUp() throws Exception {
super.setUp();
}

protected void tearDown() throws Exception {
super.tearDown();
}

@Test
public void testDuplicateMsg() throws Exception {

MqttConnectOptions client1ConnOpt = new MqttConnectOptions();
MqttClient client1 = new MqttClient(BROKER1_URL, client1);

client1ConnOpt.setCleanSession(true);
client1.connect();
System.out.println(Client1 Connected to  + BROKER1_URL);
client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);
Thread.sleep(2000);
client1.disconnect();
System.out.println(Client1 completed cleansession=1 
subscription.);


client1ConnOpt.setCleanSession(false);
client1.setCallback(this);
client1.connect(client1ConnOpt);

System.out.println(Client1 Connected to  + BROKER1_URL);
client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);
Thread.sleep(2000);
client1.disconnect();
System.out.println(Client1 completed durable subscription.);

MqttConnectOptions client2ConnOpt = new MqttConnectOptions();
client1ConnOpt.setCleanSession(true);
MqttClient client2 = new MqttClient(BROKER1_URL, client2);
client2.setCallback(this);
client2.connect(client2ConnOpt);
client2.publish(paho/test, hello world.getBytes(), 
MQTT_QOS_ATMOSTONCE, false);
System.out.println(Client2 published);
client2.disconnect();



client1ConnOpt.setCleanSession(false);
client1.setCallback(this);
client1.connect(client1ConnOpt);

System.out.println(Client1 Connected to  + BROKER1_URL);
client1.subscribe(paho/test, MQTT_QOS_ATMOSTONCE);

mLatch = new CountDownLatch(1);
mLatch.await(10, TimeUnit.SECONDS);
assertEquals(Success!, true, mMessageReceived);
System.out.println(Done);
}

@Override
public void connectionLost(Throwable arg0) {
// TODO Auto-generated method stub

}

@Override
public void deliveryComplete(IMqttDeliveryToken arg0) {
// TODO Auto-generated method stub

}

@Override
public void messageArrived(String topic, MqttMessage message) throws 

[jira] [Updated] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5358:

Attachment: (was: MqttDurableSubTest.java)

 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR

 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Junit test code attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR updated AMQ-5358:

Attachment: MqttDurableSubTest.java

JUnit test case for MQTT durable subscriptions using MQTT Paho client library.

 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR
 Attachments: MqttDurableSubTest.java


 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Junit test code attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14134539#comment-14134539
 ] 

AR commented on AMQ-5358:
-

The proper behavior is that messages that are published to consumers that are 
offline should be delivered to the consumers when they eventually come online. 

What I have observed is that the messages are not delivered when the consumers 
come online. I have verified that the messages do get published to the topic 
(using the web console).

The same test case is successful when I run broker version 5.9.0.



 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR
 Attachments: MqttDurableSubTest.java


 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Junit test code attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14134580#comment-14134580
 ] 

AR commented on AMQ-5358:
-

I just downloaded apache-activemq-5.11-20140914.222907-84-bin.tar.gz and ran 
default broker without any change. My test case failed.
If I replace the broker with 5.9.0, it works. 
What could I be doing wrong?

 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR
 Attachments: MqttDurableSubTest.java


 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Junit test code attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14134641#comment-14134641
 ] 

AR commented on AMQ-5358:
-

my mistake. Didn't realize that QoS 0 messages are not stored. Thanks for your 
help!

 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR
 Attachments: MqttDurableSubTest.java


 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Junit test code attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (AMQ-5358) MQTT Durable subscription broken in 5.10 and 5.11

[AR (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

AR closed AMQ-5358.
---
Resolution: Not a Problem

 MQTT Durable subscription broken in 5.10 and 5.11
 -

 Key: AMQ-5358
 URL: https://issues.apache.org/jira/browse/AMQ-5358
 Project: ActiveMQ
  Issue Type: Bug
  Components: MQTT
Affects Versions: 5.10.0, 5.11.0
 Environment: Mac OS X, MQTT Paho client library version 0.4.0
Reporter: AR
 Attachments: MqttDurableSubTest.java


 Durable subscriptions do not work in 5.10 and 5.11-SNAPSHOT.
 Test case:
 Run default broker.
 . Connect client1 with clean_session=true.
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Disconnect client1
 . Connect client2
 . Publish message hello world to topic paho/test
 . Disconnect client2
 . Connect client1 with clean_session=false
 . Subscribe to topic paho/test
 . Verify that the message is received.
 Junit test code attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)