activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Bragatti <>
Subject Possible Bug Apollo Durable Subscriptions
Date Fri, 16 Aug 2013 21:21:33 GMT
Hi there,

I'm struggling against a possible issue using Apollo MQTT and it's durable
subscriptions. My intention is to synchronize a client using QOS 1.

Here is my setup:

Apollo Dev Snapshot, based on: 20130803 tarball
Mosquitto (Pub, Sub and Lib) 1.2.0

I noticed that some client messages were on the dsub queue but got stuck
there and wouldn't be delivered. I suspected on my custom client and tried
some testing using Mosquitto.

So, I started by running the mosquitto broker:
> mosquitto -p 61613

Then (in another terminal, same machine) I started a client using:
> mosquitto_sub -h  -p 61613 -q 1 -c -i my_id -t foo

I killed the mosquito_sub by ctrl-c and published some messages to the foo
> for I in {1..10}; do (mosquitto_pub -h -p 61613 -t foo -q 1
-m "$I") done

Finally, I restarted the mosquito_sub and got all the messages, in order
(which is quite important in this application):
> mosquitto_sub -h  -p 61613 -q 1 -c -i my_id -t foo

I also tried having sub and pub running both at the same time, results were
as expected. Actually, I even tried killing the mosquitto_sub proccess in
the middle of the stream and restarting it again while the mosquitto_pub
bash loop was still running. It received all the messages and kept ordering.

I then repeated this testing session using the Apollo broker instead of
mosquitto. These were my results:

1) In the first test scenario, mosquitto_sub won't receive any messages.
They will remain on the dsub forever. I might mention that there's a
stranger acquirer unknown on the dsub's web interface and by consulting the
dsub's rest API there's indication of consumers position being 11 (or
number of messages+1).

2) During the drop during the loop test. I got all the messages that were
published when both parties were running, but not those that were still on
the dsub and were sent when the mosquitto_sub was down.

These results lead me to suspect of Apollo's consumer's position tracking
systems on dsubs, which seems not to keep track of the last consumed
message properly.

Can you reproduce this test or offer an explanation for the diverging
behaviors between the mosquitto broker and Apollo?

Best Regards,

L. Bragatti

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message