activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Posta <christian.po...@gmail.com>
Subject Re: Possible Bug Apollo Durable Subscriptions
Date Mon, 19 Aug 2013 17:17:49 GMT
So I can recreate something *similar*.

If I just run it as you describe:

* mosquitto_sub -h 172.16.1.220  -p 61613 -q 1 -c -i my_id -t foo
* then kill mosquitto_sub
* run producer > for I in {1..10}; do (mosquitto_pub -h 172.16.1.220 -p
61613 -t foo -q 1 -m "$I") done
* then restart mosquitto_sub

it works just fine....

but if I happen to do this, then I can reproduce what you see on Apollo:

* mosquitto_sub -h 172.16.1.220  -p 61613 -q 1 -c -i my_id -t foo
* then kill mosquitto_sub
* run consumer again: mosquitto_sub -h 172.16.1.220  -p 61613 -q 1 -c -i
my_id -t foo
* then kill mosquitto_sub
* run producer > for I in {1..10}; do (mosquitto_pub -h 172.16.1.220 -p
61613 -t foo -q 1 -m "$I") done
* then restart mosquitto_sub

Seems to wok on mosquitto. I'll take a closer look when I get a sec....




On Fri, Aug 16, 2013 at 2:21 PM, Leonardo Bragatti
<lbragatti@tegris.com.br>wrote:

> 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 172.16.1.220  -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
> channel:
> > for I in {1..10}; do (mosquitto_pub -h 172.16.1.220 -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 172.16.1.220  -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
>



-- 
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta

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