[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mosquitto-dev] Thread race between mosquitto_disconnect and mosquitto_loop_stop [EXTERNAL]
|
Hi All,
I am not suggesting the sleep(1) as a fix or having it as part of my
code. It is there to demonstrate that if there is any time gap between
the mosquitto_disconnect() and mosquitto_loop_stop() call I get the
MOSQ_ERR_INVAL.
This still happens if I install connect and disconnect handlers and wait
for the disconnect handler to be called before calling
mosquitto_loop_stop(). The problem is the thread that mosquitto starts
to handle the requests will exit after mosquitto_disconnect() is called
and this sets the mosq->threaded state variable to a value that causes
it to return with an
error instead of continuing on to do the pthread_join.
Regards,
Denis
On 16/03/2023 9:00 pm, Martens(EXT), Yves via mosquitto-dev wrote:
Hi,
Adding my 50c, because I'm also interested in the official guidance and faced my own problems and frustrations in this area. But I'm no expert on this or maintainer of the package:
- I think first disconnecting then loop_stop is correct.
- instead of step 5 (sleep 1), I would recommend observing a bool m_bConnected, which can be set/unset from mosquittopp::on_connect/ mosquittopp::on_disconnect, where you can also observe the reason code 'rc' which the broker should send. Only proceed to loop_stop once you are confirmed as disconnected. Hopefully you can match that up with what the broker is itself reporting (either in its own logs or via mosquittopp::on_message) and get further from that additional debug info.
- A related usecase is that of a client disconnecting because a different client connected with the same name. This is not a usual usecase, but still something we would not want the software to fail on. Then the first client gets disconnected (on_disconnect) without its own initiative, but how to properly stop then? The loop_stop (which does a mosquitto-loopthread.join()) needs to be called from the main thread not from the on_disconnect (which is called on the mosquitto-loopthread)).
https://groups.google.com/g/mqtt/c/J-_iBkefJo8/m/rmQG6FQkS18J
Good luck!
Kind regards,
Yves
-----Original Message-----
From: mosquitto-dev <mosquitto-dev-bounces@xxxxxxxxxxx> On Behalf Of Gellman, Rebecca
Sent: Tuesday, March 14, 2023 9:45 AM
To: General development discussions for the mosquitto project <mosquitto-dev@xxxxxxxxxxx>
Subject: Re: [mosquitto-dev] Thread race between mosquitto_disconnect and mosquitto_loop_stop [EXTERNAL]
Hi,
I'm also interested in clarification on this issue. We use mosquitto_loop_start in our application as it uses an event-driven model. Occasionally, libmosquitto returns "unknown error" and the connection appears dead, however there doesn't seem to be a clear way to reconnect. I read that the mosquitto loop thread would be dead at this point, so I added code to stop the loop, destroy the context, and start again from scratch but this doesn't always work - sometimes returning "Invalid Input" (as seen below), and sometimes locking up the whole application (as evidenced by the systemd watchdog stepping in with extreme prejudice).
Would love to hear some official guidance.
Regards
Rebecca Gellman
-----Original Message-----
From: mosquitto-dev <mosquitto-dev-bounces@xxxxxxxxxxx> On Behalf Of Denis Dowling
Sent: 13 March 2023 03:14
To: mosquitto-dev@xxxxxxxxxxx
Subject: [mosquitto-dev] Thread race between mosquitto_disconnect and mosquitto_loop_stop [EXTERNAL]
WARNING: This message came from an external source. Please exercise caution and proper judgment when opening any attachments, clicking links or responding to this message.
Hi All,
I am having some difficulty shutting down mosquitto client threads cleanly.
Attached is a small test program that does:
1) mosquitto_new()
2) mosquitto_connect()
3) mosquitto_loop_start()
4) mosquitto_disconnect()
5) sleep(1)
6) mosquitto_loop_stop()
If I run the program I get a MOSQ_ERR_INVAL return from mosquitto_loop_stop(). The mosq->threaded state is mosq_ts_none instead of the expected mosq_ts_self. This state gets changed when the
mosquitto__thread_main() exists. This function changes the state from mosq_ts_self back to mosq_ts_none on thread exit.
I am stuck on how to deal with this in my code. If I ignore the error from mosquitto_loop_stop() then there is a small amount of memory leaked as the pthread_join() call is never called and this shows up on my valgrind reports.
Even without the sleep() call the program will sometimes fail if the
mosquitto__thread_main() manages to exit before the
mosquitto_loop_stop() gets called in the main thread. I have noticed this periodic failure on my unit tests.
I think the code in mosquitto__thread_main() that sets mosq->threaded back to mosq_ts_none should be removed or perhaps it needs an extra state for mosq_ts_self_exit.
Happy for someone to point out a better solution :-)
Regards,
Denis
----------------------------------------------------------------------
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this e-mail and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.
For information about how we process personal data and monitor communications, please visit https://www.curtisswright.com/privacy-notice/default.aspx
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev
This message is subject to the following terms and conditions: MAIL DISCLAIMER<https://www.barco.com/en/maildisclaimer>
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev
