Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Mosquitto c++ lib unexpected disconnect.

Hi Adam,

In principle it sounds like what you're doing should be fine. I've
only a few thoughts at this point I'm afraid. The first is as to
whether you've tried your client with a different broker? There's no
particular reason to suspect rabbit of being at fault but it ought to
be a relatively straightforward thing to try (without knowing what
else you're doing of course :) that eliminates an unknown.

The other point is about what you're doing in the on_message callback.
Is it possible that occasionally a part of that function introduces a
lot of latency that causes a disconnect due to inactivity? WIth
keepalive of 60 if seems unlikely of course.



On Fri, Apr 15, 2016 at 9:20 PM, Sunderman, Adam
<Adam.Sunderman@xxxxxxxxxxxx> wrote:
> Hi,
> I am running Mosquitto lib version 1.4.8 and am handling a connection to a
> broker (rabbitMQ) with mqtt protocol version 3.1.1.
> I have all mosquitto functionality encapsulated in a c++ object
> (MQTT_Handler). I call mosquitto_lib_init() in the constructor. in
> MQTT_Handler::init() function, I use mosquitto_new() and use the this
> pointer as the obj parameter to re-scope the callbacks to my c++ object. I
> then proceed in the same function to call mosquitto_loop_start(), set the
> protocol version to 3.1.1, set relevant callbacks,
> mosquitto_reconnect_delay_set(), mosquitto_max_inflight_messages_set().
> After my object is initialized, the function MQTT_Handler::connectToBroker()
> will eventually be called where I mosquitto_username_pw_set(), and
> mosquitto_connect_async().
> After this point, most of the interaction with mosquitto happens via the
> callbacks fired. i.e. on the connect callback I subscribe to topics that my
> c++ object has been told to subscribe to, on the message_callback I pass the
> message onto the entity that cares about it, i.e. The only thing that my
> object does periodically outside of the callbacks is publish messages that
> other entities ask it to publish.
> Everything works very well for a time. I am logging everything but DEBUG
> level messages (and am seeing nothing in that regard, so I may have to add
> DEBUG to pinpoint the cause of the issue). However after prolonged runtimes,
> I will occassionally get an unexpected disconnect (the disconnect callback
> will fire and reason will not be 0. note: timeout is 60 seconds). However,
> communication with the broker seems fine even after this occurs according to
> ping and the reconnect never seems to happen (well atleast not the connect
> callback) despite me setting up the reconnect info for the mosquitto thread.
> Making the issue stranger is the fact that at a low level, the connection
> seems to be fine and actually is running. I can perform a netstat -tapen and
> see that I still have an active connection to my broker. If I look in the
> rabbitmq management interface I also see that the queue still has a consumer
> (and the ip-port matches my netstat result). Furthermore, if I publish to
> this queue, the consumer even acks it despite my application not receiving
> any callbacks from mosquitto.
> I have tried to be detailed in how I am utilizing mosquitto and the sequence
> of events, but I'm sure this won't be enough information alone. If I can be
> pointed in the right direction for what info I need to attain when the issue
> occurs, I can work towards gathering it. Unfortunately, it is tough to
> recreate at will, I just have to let it run for extended periods of time and
> then comb back through the logs to look for irregularities.
> Any help is greatly appreciated!
> Thanks,
> Adam
> This email is intended solely for the use of the individual to whom it is
> addressed and may contain confidential and/or privileged material. Any views
> or opinions presented are solely those of the author and do not necessarily
> represent those of AGCO. If you are not the intended recipient, be advised
> that you have received this email in error and that any use, dissemination,
> forwarding, printing or copying of this email is strictly prohibited.
> Neither AGCO nor the sender accepts any responsibility for viruses and it is
> your responsibility to scan and virus check the e-mail and its attachment(s)
> (if any).
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit

Back to the top