Skip to content
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

Improve HttpConnection buffer recycling #12227 #12228

Closed
wants to merge 6 commits into from

Conversation

gregw
Copy link
Contributor

@gregw gregw commented Sep 2, 2024

Fix #12227 by improving/clarifying buffer recycling

Added more tests to better check the behaviour

Improved tests to indicate the issues.
@gregw gregw self-assigned this Sep 2, 2024
@gregw gregw requested review from sbordet and lorban September 2, 2024 22:44
@gregw gregw marked this pull request as ready for review September 4, 2024 01:57
Copy link
Contributor

@sbordet sbordet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gregw I think the current changes have a number of issues.

I'll try myself on another PR.

Comment on lines +513 to +514
// We are not in a race here for the request buffer as we have not yet received a request,
// so there are not any possible legal threads calling #parseContent or #completed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment is incorrect.
This method is called from parseAndFillForContent(), which is called by the application either reading or demanding, so a request has indeed been received.

@@ -411,30 +422,36 @@ public void onFillable()
if (_handling.compareAndSet(true, false))
{
if (LOG.isDebugEnabled())
LOG.debug("request !complete {} {}", request, this);
LOG.debug("request !complete {} {} {}", request, this, _requestBuffer);
releaseRequestBufferIfEmpty();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in a race with the application, so we cannot release at all here.
A thread spawned by the application can read request content, possibly leading to unexpected NPEs.

releaseRequestBuffer();
}
else if (filled < 0)
_parser.atEOF();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cannot remove buffer release from this method, because this method is called from parseAndFillForContent() (which does not release buffers), so reading the request content would never release the buffer.

Comment on lines +1560 to +1562
// The handling thread has completed, so we can free up any empty buffer here
releaseRequestBufferIfEmpty();

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea of not releasing here is that we can re-use an empty existing buffer for the next request, rather than releasing here, and having to re-acquire it for the next request.

sbordet added a commit that referenced this pull request Sep 4, 2024
Alternative to #12228.

In this PR, the responsibility to release the buffers is in 2 methods: onFillable() (called when network data is available, and to process the next request) and parseAndFillForContent() (called from Request.read()).

Signed-off-by: Simone Bordet <[email protected]>
@sbordet
Copy link
Contributor

sbordet commented Sep 4, 2024

@gregw see #12237.

@gregw gregw closed this Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

Improve HttpConnection buffer recycling
2 participants