High number of close event listeners

[dgg]

Hello,

In our project we are using mqtt v4.2.1 to communicate to an EMQX broker through websockets.

The installation has a record of network instability (we often get disconnet, reconnect, connect cycles. It usually -but not always- reconnects straight away).

Since upgrading to the aforementioned version, we have seen that sometimes (we cannot find a pattern), a high number of listeners to the "close" events are attached. (we have seen numbers in the thirties and forties) and it is not our code that is attaching such listeners (our code only attaches one listener to each one of the events, except messages that 3 listeners are attached).

As a result of such a high number of listeners, node runtime writes a warning about a possible memory leak. And, sometimes (we found not trigger or pattern), a side effect is degraded communication with the client (messages don't arrive). We do not observe the communication problems while the warning has not been printed.

We have also observed that the number of listeners decreases, most of the time to the initial low number of 2.

The application sends messages with qos of 0, but also some messages with qos of 1 and 2.

Is this increase number of listeners to the close event a normal behavior? It feels odd that the runtime prints a warning for a normal behavior, even more so when some point afterwards the printing we see communication problems.

Let me know if you need more information about the issue.

[YoDaMa]

is this a recent instability? Is there a previous version that does not have these instability issues?

[dschonholtz]

#1152 Might be relevant. It is still open but there are some work arounds in it.

[dgg]

is this a recent instability? Is there a previous version that does not have these instability issues?

Unfortunately, this customer has not had the previous version to compare against. Other customers did not exhibit the same instability (but they do not have as many disconnections either). Other customers that have the latest version of the library do not have the listeners warning.

[dgg]

#1152 Might be relevant. It is still open but there are some work arounds in it.

Uhm, I am not sure it is relevant as we do not call .reconnect(). The reconnection attempts (and eventual connection success) are performed by the library itself when there is a disconnection. Besides, we do not see an endless connect/disconnect loop. We only observe that once in a while the connection is dropped and inmediately picked up again (or some time later if it is a proper networking hiccup).

Does one need to call .reconnect() oneself on a scheduled manner or upon disconnection? I thought that was done by the library automatically unless specified otherwise...

[dschonholtz]

Nope, if you aren't calling reconnect then I don't think you need to worry about it. I misread your post and thought you were seeing a large number of close events getting triggered, which I thought sounded like the outstanding issue. My mistake.

[github-actions[bot]]

This is an automated message to let you know that this issue has gone 365 days without any activity. In order to ensure that we work on issues that still matter, this issue will be closed in 14 days.

If this issue is still important, you can simply comment with a "bump" to keep it open.

Thank you for your contribution.

[github-actions[bot]]

This issue was automatically closed due to inactivity.