Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Detecting disconnects

Hi Andrew,

Ok, in that case I definitely don't see this. Some more questions for you:

What platform are you running on?
Is the broker on the same machine as the client?
Are you using ssl?
How many seconds is it between your calls to loop()?

Cheers,

Roger

On Jan 20, 2015 7:32 PM, "Andrew McClure" <andrew@xxxxxxxxxxxxxx> wrote:
Hi Roger

The use case is very simple. I am polling loop() every x seconds and checking for a return value of 0.

I kill the broker - control C or whatever - as part of a robstness test.

The code code automatically tries to reconnect so that's how I detect the error 61 - Connection Refused = socket error.

http://southweb.co.nz/telemetrylayer (this is our QGIS plugin but I don't expect you to have to download and understand it)


On 21/01/2015, at 6:31 am, Roger Light <roger@xxxxxxxxxx> wrote:

> Hi Andrew,
>
> I agree, not very useful. I can see where those return codes would
> happen, but I've not been able to reproduce the behaviour myself. Can
> you give me any more details on what you are doing? You should see a
> printed error message as well when you get a 1 returned. Did you see
> that and if so what was it?
>
> I think this whole area might need a bit of a rethink for Paho 1.2.
>
> Cheers,
>
> Roger
>
>
> On Sun, Jan 18, 2015 at 1:13 AM, Andrew McClure <andrew@xxxxxxxxxxxxxx> wrote:
>> Am wondering the best way to manage error handling and reporting of > 0 return values from loop().
>>
>> e.g. the return value from loop() after the broker has gone away is initially the rc value - typically 1 (MQTT_ERR_NOMEM)
>>
>>        if self.socket() in socklist[0]:
>>            rc = self.loop_read(max_packets)
>>            if rc or (self._ssl is None and self._sock is None):
>>                return rc
>>
>> This is a little hard to report meaningfully. It is only on the subsequent reconnect attempt that we get the errno 61 - Connection Refused.
>>
>> Am thinking that ignoring or printing a debug statement with the returned rc value is the best we can hope for.  Thanks.
>>
>>
>> _______________________________________________
>> 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
> _______________________________________________
> 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

_______________________________________________
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