This seems to be related BTW:
https://issues.apache.org/jira/browse/APLO-336
On Mon, Aug 19, 2013 at 10:17 AM, Christian Posta <christian.po...@gmail.com
> wrote:
> 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
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
