migrated from Bugzilla #407909
status CLOSED severity major in component MQTT-JS for ---
Reported in version v0.5 on platform PC
Assigned to: Andrew Banks
On 2013-05-13 11:34:06 -0400, Alexander Rust wrote:
Hi,
I just started playing with the Paho-Js client and tried to plug it into the existing code for a home-automation webinterface that is yet based on the mosquitto.js client. The client is set to subscribe to a some topics, for which it receives ~50 retained messages from a Mosquitto broker (v. 1.1.3) after the subscription.
Sometimes the onMessageArrived method is called with one message for which the destination name and payload string are correct.
In this case my code correctly reports
topic:/devices/158212-Socket-11011-00001/controls/Power/meta/type
payload:switch
However, mostly the method ends up being called once for ~30 message with the destination name and payload string messed up totally.
I'm not sure whether I'm just wrongly assuming that the onMessageArrived method is called once for each received message or if message.payloadString has some weirdness going on.
In either case, accessing the payloadString often results in parseUTF8 errors:
Additionally, or related to the above isse the string "cleanSession" seems to end up as the payloadString.
Please let me know if there is additional information that I should provide for this issue.
On 2013-05-13 11:54:57 -0400, Andy Piper wrote:
Thanks, hopefully Andrew can respond on expected behaviour of the JS client.
On 2013-05-15 00:55:19 -0400, Simon Racliffe wrote:
Alexander,
I had similar problems, using Mosquitto server, mod_websocket_mosquitto and mod_websocket. I suspect you are using a similar config. If so upgrade your Mosquitto server to the latest at https://bitbucket.org/oojah/mosquitto/downloads. Also mod_websocket_mosquitto is very simplistic and if the group of published messages is greater than 1024 bytes it WILL break.
I have written a patch for mod_websocket_mosquitto whcih properly parse the stream and passes it on correctly. I have post this on the mod_websocket_mosquitto issues pages, but have not yet had feedback from its author. Have a look at https://github.com/willem4ever/mod_websocket_mosquitto/issues/4
Cheers
Simon
On 2013-05-15 06:01:09 -0400, Alexander Rust wrote:
Thanks Simon,
using a freshly compiled version of Mosquitto showed the same issues.
Note, that I'm not using mod_websocket but https://github.com/stylpen/WSS that is written by a good friend of mine.
It's quite simple and solid, but as it was written and tested with the Mosquitto.js library I'll see whether there are some conditions that just worked with the mosquitto library.
On 2013-05-15 08:36:45 -0400, Simon Racliffe wrote:
Alexander,
It still sounds like a similar problem to what I was having where the software that wrapped the MQTT data into the websocket packets wasn't smart enough to deal with the mosquitto server sending a bunch of publish messages in a group.
I was only able to debug the problems I was having using wireshark, and almost blamed the wrong piece of software for the problem. The latest development version of wireshark also does a much better job of decoding the websocket protocol.
Hope something here helps.
Cheers
Simon
On 2013-05-16 11:50:07 -0400, Alexander Rust wrote:
The Websocket server component looks solid, Simon. I also tried it with a patched version of mod_websocket, which showed the same issues.
Additionally, when I think about it, it was able to deal with the same bunch of published messages before, with the other library.
On 2013-05-18 06:33:51 -0400, Andrew Banks wrote:
Alexander, onMessagearrived should get driven once per message.
Could you capture some client side trace, as illustrated below, so that I can see what is being sent to the client to cause it to do what you are seeing?
// Start the client tracing, the trace records capture the method calls and network flows from now on.
client.startTrace();
On 2013-05-18 07:05:54 -0400, Alexander Rust wrote:
Hi,
I gathered the following traces by starting them in the connect-onSuccess method, right before I subscribe to my topics that contain retained messages.
Trace a) was stopped in try-catch block around console.log(message.payloadString); in the onMessageArrived method where the Error: AMQJS0009E Malformed UTF data:90 -7d was thrown.
Trace b) was stopped two seconds after the subscribe when all retained messages were received from the broker.
Alexander, trace b) shows that the server is packing multiple MQTT command messages into a Websocket frame, the client assumes the server is sending it one MQTT message per frame. Your UTF-8 conversion error has probably come about because the following message has been joined on to the publication message. There is an Oasis is discussing whether WebSockets should carry multiple or partial MQTT messages in each frame.
On 2013-05-25 06:38:19 -0400, Alexander Rust wrote:
Thanks Andrew,
the Mosquitto library was perfectly happy with that kind of behavior. We modified our Websocket bridge accordingly to just send one MQTT message per Websocket frame which did fix all errors reported previously.
I think this can be closed now, thanks for your help.
migrated from Bugzilla #407909 status CLOSED severity major in component MQTT-JS for --- Reported in version v0.5 on platform PC Assigned to: Andrew Banks
On 2013-05-13 11:34:06 -0400, Alexander Rust wrote:
On 2013-05-13 11:54:57 -0400, Andy Piper wrote:
On 2013-05-15 00:55:19 -0400, Simon Racliffe wrote:
On 2013-05-15 06:01:09 -0400, Alexander Rust wrote:
On 2013-05-15 08:36:45 -0400, Simon Racliffe wrote:
On 2013-05-16 11:50:07 -0400, Alexander Rust wrote:
On 2013-05-18 06:33:51 -0400, Andrew Banks wrote:
On 2013-05-18 07:05:54 -0400, Alexander Rust wrote:
On 2013-05-20 06:02:45 -0400, Andrew Banks wrote:
On 2013-05-25 06:38:19 -0400, Alexander Rust wrote: