Fix MaxListenersExceededWarnings #55
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
We are getting this error (warning) from EventEmitter shortly after every time a k8s pod starts. Our current client / server version is 7.17 but I tried with the 8.6 client too. With 8.6 the message changes a little in the stack trace, but the result is still another log in our error logs |
|
Any updates when this fix will be merged in? We are also running into this issue. |
|
Why closing it? Has it been fixed in another PR? |
|
@skarahoda |
|
I'm taking over as the maintainer of this repo and getting familiar with it. Hoping to be able to address this issue soon. I'll track progress in #63. |
JoshMock
added a commit
that referenced
this pull request
May 1, 2024
A potential fix for #63, largely inspired by a community member's PR that was never merged: #55 According to an Undici core committer in this comment elastic/elasticsearch-js#1716 (comment) the issue that triggers the MaxListenersExceededWarning, and possibly a memory leak in some cases, is caused by attaching an EventEmitter to each request by default when a per-request timeout is set, rather than attaching an AbortSignal. My assumption is that an EventEmitter was used because AbortSignal and AbortController were not added to Node.js until v14.17.0, so we couldn't guarantee v14 users would have it. I'm not certain why using EventEmitters makes a difference memory-wise, but it does get rid of the MaxListenersExceededWarning.
JoshMock
added a commit
that referenced
this pull request
May 21, 2024
A potential fix for #63, largely inspired by a community member's PR that was never merged: #55 According to an Undici core committer in this comment elastic/elasticsearch-js#1716 (comment) the issue that triggers the MaxListenersExceededWarning, and possibly a memory leak in some cases, is caused by attaching an EventEmitter to each request by default when a per-request timeout is set, rather than attaching an AbortSignal. My assumption is that an EventEmitter was used because AbortSignal and AbortController were not added to Node.js until v14.17.0, so we couldn't guarantee v14 users would have it. I'm not certain why using EventEmitters makes a difference memory-wise, but it does get rid of the MaxListenersExceededWarning.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using the connection's emitter for undici's request causes a memory leak. In this PR, a local abort signal is used to fix the issue.
Related Issues:
elastic/elasticsearch-js#1741
elastic/elasticsearch-js#1733
elastic/elasticsearch-js#1716