Skip to content
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

Respect max_inlight message count in reconnect #698

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Juha-Ylikoski-Treon
Copy link

Previously if the message queue filled up for some reason like bad connection and the client disconnected (due to e.g. bad connection), it would send all of it's messages in _out_messages-queue and not respect _max_inflight_messages parameter. With some brokers and when we had 1000s of messages in queue and all being sent with qos 1 without any regard to the _max_inflight_messages, the broker would disconnect us or the connection would again break down.

This patch makes sure _max_inflight_messages is respected when reconnect happens for any reason.

I believe this also fixes #492

Signed-off-by: Juha Ylikoski juha.ylikoski@treon.fi

@Juha-Ylikoski-Treon Juha-Ylikoski-Treon changed the title Respoect max_inlight message count in reconnect Respect max_inlight message count in reconnect Dec 30, 2022
Previously if the message queue filled up for some reason like bad
connection and the client disconnected (due to e.g. bad connection),
it would send all of it's messages in _out_messages-queue and not
respect _max_inflight_messages parameter. With some brokers
when we had 1000s of messages in queue and all being sent with
qos 1 without any regard to the _max_inflight_messages, the broker
would disconnect us or the connection would again break down.

This patch makes sure _max_inflight_messages is respected when
reconnect happens for any reason.

I believe this also fixes eclipse-paho#492

Signed-off-by: Juha Ylikoski <juha.ylikoski@treon.fi>
PierreF added a commit that referenced this pull request Dec 25, 2023
This test is currently broken, PR #698 should fix/improve the situation
@PierreF
Copy link
Contributor

PierreF commented Dec 25, 2023

Thanks for your contribution. I've written some test in a2574e6 (pushed on master) which show the problem exist on master.

It also show that there is another problem: message are published twice, once with mid=original_mid + N and once with mid=original_mid & dup = 1.

This issue still exists on this PR. I haven't yet looked whether the two issues are unrelated (and then the PR should be merged as-is) or they are related and should be fixed together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

At reconnect, the client doesn't seem to take max_inflight_messages into account
2 participants