[
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
Thanks for the help and the fast replies. From my point of view my
favorite would be option 3. I think also option 1 would already be an
improvement and help to faster discover the problem. I think option 2
is like throwing an exception out of a destructor which I think should
be avoided.
Regards
Franz
On Fri, Sep 26, 2014 at 12:11 AM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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.
>
> Ian
>
>
> 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->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
> Franz
>
>
>
>
>
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/paho-dev
>
>
> --
> Ian Craggs
> icraggs@xxxxxxxxxx IBM United Kingdom
> Paho Project Lead; Committer on Mosquitto
>
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/paho-dev