-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Client ID not unique for a connection #9409
Comments
@ttulka |
@lafirest Thanks for the reply, I have a debug log but it contains some semi-sensitive information i don't want to share public on GitHub. Can I send you the log in a private channel (email or similar)? |
Yes, of course, My email is blankalupo@163.com |
we still have a lot of duplications with 4.4.15! There are duplications on each nodes. username and client_id is the same for each session. If we try to kickout the client by webadmin action, the DELETE API call is successful, but the session is still alive. Probably those clients have a bad internet/wlan connection, which produces a lot of reconnects, sometimes one reconnect per minute. It is possible that this high connection rate of the same client produces such faulty sessions? And those clients receive old retained messages each time after reconnect (which are already cleared up several hours ago). @lafirest do you have any suggestions how we can get more details about the cause which can help you to fix the bug? Thanks! Search result from one node (All clients are using MQTT v3.1.1): |
@gbrehmer |
There had been a few similar issues reported on different versions, and we have failed to reproduce it so far. |
Had an online session with @gbrehmer. With some debugging commands we were able to identify the root cause of this: the deferred worker pool member is overloaded by retained message scans/dispatches, hence also delaying the clean-ups of the stale connections (which also relies on the same worker pool). steps to confirm if it's the same cause when similar behaviour is observed:
In such case, the stale clients visible from the dashboard will eventually disappear, it does not affect anything. To fix it, there are 2 TODOs for EMQX team:
|
@zmstone thanks again for the session. We identified another problem on our side during this session, which produces a lot of uncleared retained messages (2,7M messages = 1.8 GB ets DB size, expected message count: < 100k). Now the load could be reduced by cleaning up these old messages. |
What happened?
When a client sets a timeout greater than the idle_timeout for zone:mqtt it happens that multiple connections with the same client ID are kept active.
What did you expect to happen?
Only one active connection per client ID should exist as specified by MQTT.
How can we reproduce it (as minimally and precisely as possible)?
A client with a timeout greater then the broker connects multiple times.
Anything else we need to know?
No response
EMQX version
OS version
The text was updated successfully, but these errors were encountered: