-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cancelling a publish task will keep the puback waiter indefinitely (QOS > 0) #126
Comments
pazzarpj
added a commit
to pazzarpj/amqtt
that referenced
this issue
Dec 4, 2022
Added tests to find case of cancelled QOS > 0 messages
pazzarpj
added a commit
to pazzarpj/amqtt
that referenced
this issue
Dec 4, 2022
Added message clean up on cancelled publish messages
pazzarpj
added a commit
to pazzarpj/amqtt
that referenced
this issue
Dec 4, 2022
- Updated protocol handlers to more reliably remove active waiters when task cancellation occurs - Fixed checks where expecting a KeyError when it should be checking if not None - Updated next_packet_id property to correctly check if there are any packet_ids available. Avoids infinite loop if all packet ids are used.
Unit tests are written on the PR which can reproduce this issue on the master and are solved in the PR
|
pazzarpj
added a commit
to pazzarpj/amqtt
that referenced
this issue
Jan 9, 2023
pazzarpj
added a commit
to pazzarpj/amqtt
that referenced
this issue
Jan 11, 2023
pazzarpj
added a commit
to pazzarpj/amqtt
that referenced
this issue
Jan 11, 2023
- Updated protocol handlers to more reliably remove active waiters when task cancellation occurs - Fixed checks where expecting a KeyError when it should be checking if not None - Updated next_packet_id property to correctly check if there are any packet_ids available. Avoids infinite loop if all packet ids are used.
FlorianLudwig
pushed a commit
that referenced
this issue
Feb 27, 2023
- Updated protocol handlers to more reliably remove active waiters when task cancellation occurs - Fixed checks where expecting a KeyError when it should be checking if not None - Updated next_packet_id property to correctly check if there are any packet_ids available. Avoids infinite loop if all packet ids are used.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm currently on hbmqtt but am considering porting to amqtt due to this bug. However this bug still exists.
I came across this issue when cancelling publish messages (using wait_for) after 10 seconds if not acknowledged on an embedded system. If the message was not acknowledged in time, the pub ack waiter would stay in memory forever.
Code to reproduce this error below. This will send 1000 messages in parallel. It will cancel a portion of them every loop before they receive the puback from the broker. Then they will print out the log message PUBACK waiter with Id 'x' already done. Eventually, all 65535 message ids will be taken and no new messages will send and the client will get stuck in a while loop forever looking for "next_packet_id" as there are none available.
Requires a mqtt broker on 127.0.0.1 to work
The text was updated successfully, but these errors were encountered: