-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Fixes #12122 - NPE in HttpReceiver.responseContentAvailable(). #12123
Conversation
Now also the HttpReceiver.responseContentAvailable() is serialized, so that the access to `this.contentSource` is serialized with failure, and protected by a call to `exchange.isResponseCompleteOrTerminated()`. Before, it was possible that a thread failed the response, nulling out `this.contentSource`, while another thread was just about to call `responseContentAvailable()` -- this was the case for HTTP/2 in particular, where content is notified asynchronously, rather than being created by a call to `ContentSource.read()`. Signed-off-by: Simone Bordet <[email protected]>
@sbordet can you stage artifacts for me to test? |
I can confirm that this change fixes the issue that we've seen in our benchmarks while running with HTTP/2 |
* This method directly invokes the demand callback, assuming the caller | ||
* is already serialized with other events. | ||
*/ | ||
protected void responseContentAvailable() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this method be private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it is called from other places when it's known that there is no need to serialize.
Added test case. Signed-off-by: Simone Bordet <[email protected]>
Now also the HttpReceiver.responseContentAvailable() is serialized, so that the access to
this.contentSource
is serialized with failure, and protected by a call toexchange.isResponseCompleteOrTerminated()
.Before, it was possible that a thread failed the response, nulling out
this.contentSource
, while another thread was just about to callresponseContentAvailable()
-- this was the case for HTTP/2 in particular, where content is notified asynchronously, rather than being created by a call toContentSource.read()
.