MQTT Websockets Last Will Message Not Going Through

[Watson Yim]

Hi RabbitMQ Team,

Thank you for your time.

I am having an issue with the last will while using the websocket MQTT plugin; the last will is not sent on an abnormal disconnect. I have tested last will via CLI using mosquitto_pub, and forcibly closing the connection (ctrl-c): 

$ mosquitto_pub -t 'test/topic' -h 12.34.56.78 --will-topic 'dead/topic' --will-qos 0 --will-payload 'deadpayload' -l

On client connect, broker logs

=INFO REPORT==== 17-Nov-2016::01:33:15 ===

MQTT accepting TCP connection <0.5170.0> (87.65.43.21:55613 -> 10.0.0.164:1883)

=INFO REPORT==== 17-Nov-2016::01:33:15 ===

accepting MQTT connection <0.5170.0> (87.65.43.21:55613 -> 10.0.0.164:1883)

And publishes successfully the last will message in:

$ mosquitto_sub -t '#' -h 12.34.56.78 -v

dead/topic deadpayload

On client forced disconnect, broker logs

=INFO REPORT==== 17-Nov-2016::01:27:15 ===

MQTT detected network error for "87.65.43.21:63542 -> 10.0.0.164:1883": peer closed TCP connection

However, using Paho client, I am unable to trigger the last will. I attempt to trigger the last will be closing the browser. Using the same script with Mosquitto, I am able to trigger the last will message via closing the browser. 

My test script is:

var host = '12.34.56.78';

var port = 15675;

var path = '/ws';

var clientId = 'mqttPahoTest';

var client = new Paho.MQTT.Client(host, port, path, clientId);

var lastWill = new Paho.MQTT.Message('deadwspayload');

lastWill.destinationName = 'dead/topic/ws';

lastWill.qos = 0;

lastWill.retained = false;

client.connect({

keepAliveInterval: 60,

useSSL: false,

willMessage: lastWill,

onSuccess: function() {

console.log('onConnected');

}

});

On client connect, broker logs

=INFO REPORT==== 17-Nov-2016::02:15:09 ===

accepting Web MQTT connection <0.25643.0> (87.65.43.21:56428 -> 10.0.0.164:15675)

On client disconnect, broker logs

=INFO REPORT==== 17-Nov-2016::02:18:00 ===

closing WEB-MQTT connection <0.25643.0> (87.65.43.21:56428 -> 10.0.0.164:15675)

And nothing is published on the wildcard subscribe.

I am currently using Rabbit 3.6.5, with rabbitmq_mqtt 3.6.5 and rabbitmq_web_mqtt obtained from here. On the client side, I am using MQTT Paho Javascript 1.0.1, obtained from here. 

My /etc/rabbitmq/rabbitmq.config is as follows:

[

 {kernel, [

  ]},

 {rabbit, [

   {cluster_nodes, {[], disc}},

   {cluster_partition_handling,ignore},

   {tcp_listen_options, [binary, {packet,raw},

                                 {reuseaddr,true},

                                 {backlog,128},

                                 {nodelay,true},

                                 {exit_on_close,false},

                                 {keepalive,false},

                                 {linger, {true,0}}]},

   {log_levels, [{ connection, debug }]},

   {default_user, <<"admin">>},

   {default_pass, <<"adminMe">>},

   {heartbeat, 580}

 ]}

 ,{rabbitmq_mqtt, [

   {default_user, <<"admin">>},

   {default_pass, <<"adminMe">>},

   {allow_anonymous, true},

   {vhost, <<"/">>},

   {exchange, <<"amq.topic">>},

   {subscription_ttl, 3600},

   {prefetch, 10},

   {ssl_listeners, []},

   {tcp_listeners, [1883]},

   {tcp_listen_options, [

     {backlog, 128},

     {nodelay, true}

   ]}

 ]}

].

Any suggestions?

[Watson Yim]

Update, this problem is seen on 3.6.5 erlang R1603 and 19.2.

[Michael Klishin]

It could be https://github.com/rabbitmq/rabbitmq-mqtt/issues/74.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Watson Yim]

That issue looks like its related to retained messages. This is related to the web-mqtt plugin. I'm not an erlang developer, but I suspect there is no case for unexpected tcp disconnect handled. I will test to see if this problem persists on 3.6.7, erlang 18.3.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Klishin]

What you are linking to is a callback for when a WebSocket connection

terminates. It is invoked by Cowboy, the WebSocket and HTTP server RabbitMQ

uses in several plugins.

If you trace down where that callback is invoked, you'd end up in (note: I'm looking

at the 1.1.x branch, the function was renamed in master)

 * https://github.com/ninenines/cowboy/blob/1.1.x/src/cowboy_websocket.erl#L211

 * https://github.com/ninenines/cowboy/blob/1.1.x/src/cowboy_websocket.erl#L525

 * https://github.com/ninenines/cowboy/blob/1.1.x/src/cowboy_websocket.erl#L750

so yes, socket errors, closure and a bunch of other terminal conditions are handled

by Cowboy.

Please give 3.6.7.RC1 a try and provide full logs (off list) in case you still can reproduce it.

We can't delay 3.6.7 much further but certainly can release 3.6.8 or 3.6.9.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Watson Yim]

Hi Michael,

I see, thank you for your explanation. I am still working on trying to get 3.6.7 RC1 running (getting 500 errors on mgmt), but will let you know as soon as possible.