search

rksg / gpb_mqtt_sample_client

Sample SPoT Location Push API client code and GPB binding code generator for SPoT Push API
BSD 3-Clause "New" or "Revised" License
2 stars 3 forks source link

is disable-clean-session in bridge config possible? #4

Closed rlsaurabh closed 8 years ago

rlsaurabh commented 8 years ago

I'm using setClientId("myId") and setCleanSession(false) options in the java code. I've added into mosquitto_bridge.conf queue_qos0_messages true

With this, if the client connection breaks(as in, the program stops), the next time I connect the client to the local broker, I get the lost data.

Is there anyway to get the lost data if my local broker goes down(say due to internet problem)? As of now the local broker is the single point of failure. Is there anyway to improve this?

yeongsheng-tan commented 8 years ago

@rlsaurabh I'm not familiar with the above configuration in mosquitto.conf. I just tried to look it up.

@rlsaurabh from the official mosquitto documentation, I see this:

queue_qos0_messages [ true | false ] Set to true to queue messages with QoS 0 when a persistent client is disconnected. These messages are included in the limit imposed by max_queued_messages. Defaults to false.

Note that the MQTT v3.1 spec states that only QoS 1 and 2 messages should be saved in this situation so this is a non-standard option.

Reloaded on reload signal.

  • On your question ->

Is there anyway to get the lost data if my local broker goes down(say due to internet problem)? I've personally no experience regarding the above, and I would suggest you dig around stack-overflow or google to get some more implementated solutions regarding the above requirements.

  • On your question ->

As of now the local broker is the single point of failure. Is there anyway to improve this? I'd say your observation is correct. A few ways to skin this, but I would try something like having mulitple bridged mqtt brokers tapping from the same source (so reducing/hedging potential of 1 local broker going down and losing data), then you devise a clever scheme to stream all these sources to a common message 'DB' (you may draw some inspirations from this article by Basho, which can de-dup data or such, and provide the needed dead-letter-queues/buffer/offline-data-stream capability. Then having your current client code, receive event pub from the common message 'DB'.

FYI, from our SPoT/vSPoT solution, Location GPB Push API and any mqtt data stream are all QoS0 ONLY, and our broker is also a single source of failure.

rlsaurabh commented 8 years ago

Is there any way to confirm if there is any queuing implemented on the Ruckus broker? Do you have access to their configurations? I tried testing, and didn't find any, but I might be missing something. Else I'll probably need to think(and implement) a multiple local broker solution.

yeongsheng-tan commented 8 years ago

@rlsaurabh by 'queuing', are you referring to some mechanism on the SPoT stack mqtt broker, which supports buffering undelivered messages should the broker go down?

If so, then I can confirm, we do not implement any of such. It is purely a simple QoS0 implementation with no dead-letter-queues or offline buffers, to support re-delivery of messages when the broker comes alive again after an unexpected disconnection.

rlsaurabh commented 8 years ago

Alright. Got it. Thanks for the info.