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 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.


Back to the top