* no need of creating/attaching sources twice for release as it is done in the default build
Signed-off-by: olivier lamy <oliver.lamy@gmail.com>
* comment
Signed-off-by: olivier lamy <oliver.lamy@gmail.com>
* no need to fork a lifecycle when attaching sources files
Signed-off-by: olivier lamy <oliver.lamy@gmail.com>
* Issue #4965 - WINDOW_UPDATE for locally failed stream should not close the HTTP/2 session.
Improved HTTP2Session.onWindowUpdate() code to correctly check whether
the stream is already closed, and if so, just drop the WINDOW_UPDATE.
Refactored onResetForUnknownStream() to base class.
Other small refactorings to improve logging.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Fixes#4855 - Occasional h2spec failures on CI
In case of bad usage of the HTTP/2 API, we don't want to close()
the stream but just fail the callback, because the stream
may be performing actions triggered by a legit API usage.
In case of a call to `AsyncListener.onError()`, applications may decide to call
AsyncContext.complete() and that would be a correct usage of the Servlet API.
This case was not well handled and was wrongly producing a WARN log with an
`IllegalStateException`.
Completely rewritten `HttpTransportOverHTTP2.TransportCallback`.
The rewrite handles correctly asynchronous failures that now are executed
sequentially (and not concurrently) with writes.
If a write is in progress, the failure will just change the state and at the
end of the write a check on the state will determine what actions to take.
A session failure is now handled in HTTP2Session by first failing all the
streams - which notifies the Stream.Listeners - and then failing the session
- which notifies the Session.Listener.
The stream failures are executed concurrently by dispatching each one to a
different thread; this means that the stream failure callbacks are executed
concurrently (likely sending RST_STREAM frames).
The session failure callback is completed only when all the stream failure
callbacks have completed, to ensure that a GOAWAY frame is processed after
all the RST_STREAM frames.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Issue #4936 - Adding LargeHeaderTest to replicate issue
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Issue #4936 - Updating LargeHeaderTest to use ServerConnector
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Issue #4936 - Fail LargeHeaderTest if client detects issues.
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Issue #4936 large response header buffer corruption
If the response buffer is too large, the header buffer was released
but not nulled, then an exception thrown, which again released the
not nulled buffer. The buffer thus ends up in the buffer pool twice!
Signed-off-by: Greg Wilkins <gregw@webtide.com>
* Issue #4936 large response header buffer corruption
removed old comment
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Co-authored-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Fixes#4904 - WebsocketClient creates more connections than needed.
Fixed connection pool's `acquire()` methods to correctly take into account the number of queued requests.
Now the connection creation is conditional, triggered by
explicit send() or failures.
The connection creation is not triggered _after_ a send(),
where we aggressively send more queued requests - or
in release(), where we send queued request after a previous
one was completed.
Now the connection close/removal aggressively sends more
requests triggering the connection creation.
Also fixed a collateral bug in `BufferingResponseListener` - wrong calculation of the max content length.
Restored `ConnectionPoolTest` that was disabled in #2540, cleaned it up, and let it run for hours without failures.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Simone Bordet
Zac Duncan
Lachlan Roberts
Jan Bartel
Joakim Erdfelt
Olivier Lamy
Ludovic Orban
Chris Walker
Greg Wilkins