-
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
Subscribers using TCP transport lack the appropriate backpressure and disconnect during network congestion #5494
Comments
Hello, |
The version I've used last is 4.3.7. But I experienced the same with 4.3.6 Following is extracted from 'kubectl logs'
|
Thanks for the information. Looking at the code, this warning message appears when the erlang port corresponding to the socket is busy, and it leads to closing of the socket. |
@k32, |
I see, thanks. Could you share some details about the configuration? Do you terminate SSL on a front proxy or the broker? |
Publishers are external to the cluster and they use the port 8883 with TLS and username password authentication. |
UPDATE: |
Thanks, this information adds up with what I see in the code: https://github.com/emqx/esockd/blob/master/src/esockd_transport.erl#L151 I'll check which options can be tuned for the tcp transport. |
@k32 , |
Hello again, I believe this problem is a result of network congestion. There is an alarm for that, could you check if you see it? It looks like the TCP socket options are hardcoded in the code... |
I will double-check if transport options have changed. |
@Fidenz-Lasithh I see that |
@k32 , |
Absolutely, if my theory about network congestion is correct, then the current behavior of handing it is not correct. |
@k32 ,
It's nice to hear that. Would you be able to say in which version? |
I will discuss it with the team. I think it deserves to be backported to the next 4.3.* version, as well as 5.0, of course. |
Hi @k32 , |
|
Hi, |
yes. |
@zmstone That sounds awesome. When can I expect 4.3.10 image to be available on docker hub? |
Hi @Fidenz-Lasithh it's published, |
Please describe your problem in detail, if necessary, you can upload the log file through the attachment:
I've an EMQX broker deployed on a Kubernetes cluster using Helm. I also have a separate set of publishers who publishes to this broker and two subscribers who has shared the subscription to the same topic.
The topic is consisted of 23 levels.
When the subscribers get around 4000 messages per second, MQTT clients get disconnected. Subscribers are configured to reconnect automatically. They get disconnected as soon as they get reconnected.
I'm wondering whether there is a configuration option in EMQX broker to overcome this.
The text was updated successfully, but these errors were encountered: