|
Hi Milan,
I've responded on the issue. I tried to reproduce on MacOS and
Ubuntu, but haven't succeeded so far. I'm probably missing some
essential aspect, so if you have a test program or fuller trace,
that might help.
Ian
On 05/03/2019 15:24, Milan Tucic wrote:
Hello Ian,
I appreciate your work on the project and I am
aware of load you are currently facing. That is why I am not
insisting on the issue. On the other hand, a
feedback/label/milestone would be a good starting point.
Regarding your question, I can't confirm for
TCP. During the evaluation period, I had problem on TCP client
also, but with much more complex system (few localhost
clients, broker and bridges).
On the isolated test env, I can't reproduce it
(tried again today). There is also high number of posts on
connect semaphore, but first connect (with broker up and
running) succeeds.
Thanks,
Milan
Hi Milan,
I've been working on the Java client service release
as well as the implementation of the MQTT V5 support
in the Java client. (For the moment, I also have the
_javascript_ and embedded C clients to look after,
although unfortunately I haven't been able to focus on
those either.) In the last two weeks I've been
taking some of my unused vacation after getting the
Java service release out. I was going to get back to
looking at the C client as soon as I could,
unfortunately there was/is more work involved in the
Java client updates than I was expecting, so I felt I
had to concentrate on that to at least achieve a
service release, as that had been long overdue. A
colleague of mine was originally working on it, but
moved on before finishing, so I had to take over.
The description of the issue in 604 is 'semaphore
posted too many times'. This sounds like an
inconvenience, but perhaps not a high priority issue.
I think it's better to start with a description of the
external effects, like that below ('reconnect can take
up to 25 mins') rather than the internal behaviour, as
then it's easier to prioritize.
One question I have is, does this happen if the
connection is not using TLS?
Thanks
Ian
On
05/03/2019 09:35, Milan Tucic wrote:
Hello community,
Is there anyone who can try to reproduce
issue with reconnection on Paho C 1.3.0? In case
of a permanent connection, once it is lost, next
successful connect will be postponed depending
on number of signals sent to connect semaphore.
In my case it was more then 50 connect retries.
Depending on period, loss takes a lot of time
(e.g. 50 x 30s = 25min).
The same can't be reproduced with Paho 1.2.0.
If there something more to clarify, just ask.
Thank you,
Milan
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Eclipse Paho Project Lead & Mosquitto Committer
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.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://www.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Eclipse Paho Project Lead & Mosquitto Committer
|
