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

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


Back to the top