Merging this PR for #2199 as we currently think it is not worse than previous and the code base is definitely simpler. While JMH has shown significant benefits for this approach, we have yet been able to demonstrate them in full scale integration tests - however that is likely due to GC and thread pool issues dominating.
A `org.eclipse.jetty.http2.PEC_MODE` System property has been added to allow the EWYK scheduling to be disabled for HTTP/2 if need be.
* Implementation of #1803 proposal 2 - EITHER dispatch type for EWYK
* made code more readable
* increase small threadpools in tests for extra reserved thread
* clean up
* minor code simplifications
* Work in progress to simplify reserved thread pool
* use a single ReservedThreadPool built into the QueuedThreadPool
* fixed javadoc
* removed more old reserved thread references
* disable EWYK for h2
* fixes from review
* use EWYK for HTTP2
* Fixed javadocs, imports and QueuedThreadPool constructors.
* fix javadoc
* EWYK avoid unnecessary pendings
* after review
* fixed merge with jetty-threadpool.xml
* alternate EWYK implementations
* added jetty copyright headers
* Simplified EWYK code after review
* fixed bad merge
* Code cleanups.
* Improved Javadocs for deprecated property "reservedThreads".
* Improved Javadocs for deprecated property "reservedThreads".
* added a system property to enable only PEC for HTTP/2
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Issue #1803 - Review usage of scheduling strategies
Use a single ReservedThreadExecutor built into the QueuedThreadPool
via new interface TryExecutor.
Signed-off-by: Greg Wilkins <gregw@webtide.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Now waking up the flusher via iterate() after a reset has been received.
This ensures that frames that may have stalled are removed from the
flusher queue.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Idle timeout have a special meaning in that they become a no-operation
if the application is dispatched but idle (neither reading nor writing).
HttpChannelOverHTTP2 now forwards the idle timeout to HttpInput, which
will only change its state if it is interested in reading.
HttpInput.consumeAll() has been modified to consume all input even if
it's already failed.
Failures caused by the other peer (e.g. I/O failures or stream resets)
are now retained and will eagerly consumed any queued data to free up
the flow control windows.
Since requests cannot be connection delimited, don't call
sslEngine.closeInbound() on the server.
On the client, added a configuration parameter to allow missing
TLS Close Message, since many servers do that.
Introduced SslConnection.allowMissingCloseMessage so that it
throws in case of truncation attacks.
Implemented support in the generic HttpChannel and Request classes.
Linked HTTP/1.1 and HTTP/2 trailers to call HttpChannel, so that trailers
are now available in Servlet APIs by casting to Jetty's Request class.
The semantic is that trailers will only be available _after_ reading
the request content.
The fix notifies the transport when a reset frame is received,
allowing the transport to fail the write callback which then notifies
the application, either by throwing (in case of blocking writes) or
by calling error listeners.
Also added a guard, in HttpChannel.handle() for the ERROR_DISPATCH case,
that checks if the response is already committed, and if so, abort
the transport - similar to what's already there for 9.4.
* Issue #824 - Implement notifications of asynchronous error conditions for HTTP/2.
Introduced new method HttpChannelState.asyncError() to be called in
case of asynchronous errors, i.e. those errors that do not happen in
the HttpChannel.handle() loop.
Implemented HTTP/2 callbacks to call HttpChannelState.asyncError()
and plug in the existing error handling mechanism.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Issue #824 - Implement notifications of asynchronous error conditions for HTTP/2.
Improved implementation to ignore idle timeouts for streams and
session in case that requests are being handled, matching the HTTP/1.1
behavior.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>