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->
104.40.130.232:1883
(CLOSE_WAIT)
MqttSnGW 5632 root 14u IPv4 19362 0t0
TCP PiTwo:44666->
104.40.130.232:1883
(ESTABLISHED)
MqttSnGW 5632 root 15u IPv4 14985 0t0
TCP PiTwo:44403->
104.40.130.232:1883
(CLOSE_WAIT)
MqttSnGW 5632 root 16u IPv4 19365 0t0
TCP PiTwo:44667->
104.40.130.232:1883
(CLOSE_WAIT)
MqttSnGW 5632 root 17u IPv4 19371 0t0
TCP PiTwo:44669->
104.40.130.232:1883
(ESTABLISHED)
MqttSnGW 5632 root 18u IPv4 19427 0t0
TCP PiTwo:44674->
104.40.130.232:1883
(CLOSE_WAIT)
MqttSnGW 5632 root 19u IPv4 19446 0t0
TCP PiTwo:44676->
104.40.130.232:1883
(CLOSE_WAIT)
MqttSnGW 5632 root 20u IPv4 19488 0t0
TCP PiTwo:44680->
104.40.130.232:1883
(CLOSE_WAIT)
MqttSnGW 5632 root 21u IPv4 19505 0t0
TCP PiTwo:44682->
104.40.130.232:1883
(CLOSE_WAIT)
MqttSnGW 5632 root 22u IPv4 19543 0t0
TCP PiTwo:44686->
104.40.130.232:1883
(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.
Regards
