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
<lbraga...@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
