Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] MQTT C Client - Concurrency Question/Problem

Hi Franz,

it seems like it could be a good idea for the API to protect or warn against this in some way, because this is not a good side effect.   Some options:

1) A trace error entry if the client being destroyed is not disconnected.
2) Change destroy so that it returns an error code, and refuses to destroy the client if it is not disconnected. 
3) Change destroy so that it disconnects the client first, if it isn't already.

We can keep the bug open to make sure that the high CPU use has gone away, and for me to add a fix to protect against this, whatever that might be.


On 09/25/2014 07:58 PM, Franz Schnyder wrote:
Hi Ian

Looks like I was too fast with raising the bug. I think the problem is a result of my "wrong use" of the library API.

I tried to find out why the Socket_getReadySocket does not return 0 but always a socket even though there was no network traffic at that time. I found that my process had beside the 3 used sockets some "leaked" sockets:

   sudo lsof -a -p <pid>
   MqttSnGW  5632 root      12u  IPv4      14541      0t0     TCP PiTwo:44388-> (CLOSE_WAIT)
   MqttSnGW  5632 root      14u  IPv4      19362      0t0     TCP PiTwo:44666-> (ESTABLISHED)
   MqttSnGW  5632 root      15u  IPv4      14985      0t0     TCP PiTwo:44403-> (CLOSE_WAIT)
   MqttSnGW  5632 root      16u  IPv4      19365      0t0     TCP PiTwo:44667-> (CLOSE_WAIT)
   MqttSnGW  5632 root      17u  IPv4      19371      0t0     TCP PiTwo:44669-> (ESTABLISHED)
   MqttSnGW  5632 root      18u  IPv4      19427      0t0     TCP PiTwo:44674-> (CLOSE_WAIT)
   MqttSnGW  5632 root      19u  IPv4      19446      0t0     TCP PiTwo:44676-> (CLOSE_WAIT)
   MqttSnGW  5632 root      20u  IPv4      19488      0t0     TCP PiTwo:44680-> (CLOSE_WAIT)
   MqttSnGW  5632 root      21u  IPv4      19505      0t0     TCP PiTwo:44682-> (CLOSE_WAIT)
   MqttSnGW  5632 root      22u  IPv4      19543      0t0     TCP PiTwo:44686-> (ESTABLISHED)

I then found out that in some situation my code destroyed (MQTTClient_destroy) a connected client without a prior call to MQTTClient_disconnect which results in the 'leaked' sockets. I changed my code so it ensures it always disconnects the client prior to destroying them and the 'leaked' sockets are gone. The gateway now runs for more that one day and the CPU usage is still normal and the Socket_getReadySocket return 0 when there is no network traffic. So I'm quite confident that the problem is gone.

I will add this information to my bug report and leave it to you to decide if the library should handle a destroy without prior disconnect or if this is the responsibility of the library user.


paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

Back to the top