MQTT problem with LWT in case of forced disconnection

[nick]

Hi,

I am observing a weird behavior regarding the LWT.

My client is connecting with:

    client = mqtt.Client(clean_session=False,client_id="nico")
    client.will_set(topic="presence",payload="0",qos=1,retain=True)

If I stop manualy the program, rabbitmq sends the appropriate LWT (and notices client is not connected anymore)

If I stop the network connectivity while the program is running, rabbitmq notices immediately that client is not connected anymore BUT does not send the LWT

Why?

[Michael Klishin]

On 30 January 2015 at 13:33:08, nick (nico.sw...@gmail.com) wrote:
> If I stop the network connectivity while the program is running,
> rabbitmq notices immediately that client is not connected anymore
> BUT does not send the LWT

Looking at the code suggests Last Will is always sent. This may be a bug or something unusual
about your setup, nothing immediate stands out. We need to try reproducing. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[nick]

I have checked the log and found the following:

- when a user turns its WIFI/3g/... off while an MQTT connection is setup, this triggers a TIMEOUT there in the plugin:

handle_info(keepalive_timeout, State = #state { conn_name = ConnStr }) ->
log(error, "closing MQTT connection ~p (keepalive timeout)~n", [ConnStr]),
{stop, {shutdown, keepalive_timeout}, State};

however this does not trigger the function: send_will_and_terminate

hence the LWT not sent.

[Michael Klishin]

On 30 January 2015 at 22:15:51, nick (nico.sw...@gmail.com) wrote:
> > - when a user turns its WIFI/3g/... off while an MQTT connection
> is setup, this triggers a TIMEOUT there in the plugin:
>
> handle_info(keepalive_timeout, State = #state { conn_name
> = ConnStr }) ->
> log(error, "closing MQTT connection ~p (keepalive timeout)~n",
> [ConnStr]),
> {stop, {shutdown, keepalive_timeout}, State};
>
> however this does not trigger the function: send_will_and_terminate
>
> hence the LWT not sent.

Thank you for doing all the debugging work, this seems plausible. Should be an easy fix early next week :)

[Michael Klishin]

+rabbitmq-users

On 30 January 2015 at 23:08:33, nico swiperlab (nico.sw...@gmail.com) wrote:
> Will you potentially update the github with the fix?

GitHub repository is a mirror. It will be updated shortly after the fix passes QA and is merged
in http://hg.rabbitmq.com/rabbitmq-mqtt/.

[Michael Klishin]

On 30 January 2015 at 23:08:33, nico swiperlab (nico.sw...@gmail.com) wrote:
> Will you potentially update the github with the fix?

Fixed:
http://hg.rabbitmq.com/rabbitmq-mqtt/rev/e4b7126aab2c

GitHub mirror is synced, too:
https://github.com/rabbitmq/rabbitmq-mqtt/commit/dde9741b659aa345e9c6fe9cf6a419e82fd600cd

[nick]

Great, thanks!

Le samedi 31 janvier 2015 08:33:28 UTC, Michael Klishin a écrit :

On 30 January 2015 at 23:08:33, nico swiperlab (nico.sw...@gmail.com) wrote:
> Will you potentially update the github with the fix?

Fixed:

http://hg.rabbitmq.com/rabbitmq-mqtt/rev/e4b7126aab2c - tracked

GitHub mirror is synced, too:

https://github.com/rabbitmq/rabbitmq-mqtt/commit/dde9741b659aa345e9c6fe9cf6a419e82fd600cd - tracked

[nico swiperlab]

Hi Michael,

a developer is currently coding for me a 'timeout ack' for the mqtt plugin, so that any timeout ack leads to a msg in a amqp queue.

Would you recommend rather a 'timer approach' per un_ack... or rather a 'bulk interval approach' (every x milliseconds, clean all messages that expired in the right bucket)

The second approach is slightly less accurate but would potentially be better in term of bottleneck. What would you recommend?

Thank you so much for your feedback on this.
Best,
Nicolas

[nick]

Thank you Michael!

Could you indicate me how to update a plugin on a running server?

[Michael Klishin]

On 3 February 2015 at 00:54:55, nick (nico.sw...@gmail.com) wrote:
> Could you indicate me how to update a plugin on a running server?

It's not so straightforward with MQTT at the moment and will drop existing connections anyway.

So simply place your compiled plugin and any new dependencies (compiled to .ez files)
to the plugins directory and restart RabbitMQ.

You can also start a new node, move your clients there and then shut down the one you have. 

[nick]

When it is to get the latest version of the official plugin, is it sufficient to disable and re-enable the plugin?