Open Shadocko opened 3 months ago
Hello,
Here is the complete source code for an epoll-based command-line subscriber exhibiting the issue:
https://gist.github.com/erkoln/90a4efbf7c3f94d8c76a9a355939e2a2
I also tested this on Ubuntu 22.04 using deb packages in version 2.0.11 for both the mosquitto broker and library, as well as mosquitto 2.0.18 built from git repo.
The sample code makes unnecessary use of a thread for servicing the MQTT connection; it doesn't make any differences when calling consumer_loop()
directly from main()
but that was my attempt testing if it was a thread-related issue.
The problem seems to have something to do with the use of edge-triggered epoll. The epoll fd apparently needs to be be rearmed in more cases but I can't figure out what libmosquitto API I could base that on.
Removing EPOLLET everywhere works but I'm afraid it would cause a waste of CPU cycles.
Any suggestion would be welcome.
Best regards,
mosquitto version: 1.6.10 platform: CentOS 7.9
Hello, I'm trying to use libmosquitto in an application with many open fds. Due to issue #1299,
mosquitto_loop()
function cannot be relied upon, so I attempted to implement my own alternative based onepoll()
,mosquitto_loop_read()
,mosquitto_loop_write()
andmosquitto_loop_misc()
instead, using answer to #2335 as inspiration. The code looks like this:I'm encountering stability issues, with
mosquitto_loop_misc()
returningMOSQ_ERR_KEEPALIVE
, which is not a documented return value and seems to be returned frommosquitto__check_keepalive()
, but I don't know what to do with this result. My client eventually gets disconnected, with the following log on the broker side:When attempting this with a TLS connection, it gets worse and the client is missing a lot of messages (client is consumer-only with many topic subscriptions, managed from another thread).
Is there something I'm doing wrong, or some way I can work around this issue? Regards,