Introduced `QueuedThreadPool.maxEvictCount` to be the number of idle threads that are evicted in one idle timeout.
When set to 1 (the default), the old behavior is reproduced: expiring 1 thread every idle timeout.
When set to larger values, allows to keep around the threads for the idle timeout (in case of further load spikes), but allows to quickly recover OS memory when they are truly idle.
For example, with 2000 threads, 30 seconds idle timeout and idleTimeoutMaxShrinkCount=1, it will take 995 minutes (about 16.5 hrs) to shrink the pool back to 10 threads.
By setting idleTimeoutMaxShrinkCount=100, the thread pool can be shrunk to 10 threads in about 10 minutes.
Note also that the new algorithm is more aggressive at shrinking the thread pool.
Previously, a small load might have been sufficient to never evict any thread, because all threads could take turns at executing jobs so that threads were mostly idle but would never really idle time out.
The new algorithm is more aggressive even in presence of a small load, so that if `minThreads` are sufficient to cope with the small load, then the other threads are evicted.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: gregw <gregw@webtide.com>
Signed-off-by: Ludovic Orban <lorban@bitronix.be>
Co-authored-by: gregw <gregw@webtide.com>
Co-authored-by: Ludovic Orban <lorban@bitronix.be>
Serialize onCompleteFailure for #9059
* Fixed case where process() throws an exception.
Before, exiting the processing loop would always skip to invoke onCompleteFailure(), causing the callback to not be completed.
Now we fall through and possibly invoke onCompleteFailure() if it was not already invoked.
* Updated javadocs.
* Code cleanups.
Co-authored-by: Simone Bordet <simone.bordet@gmail.com>
* Issue #8973 - Rework KeyStoreScanner handling for symlink related changes
+ Removed changes from #8786 and #8787
+ More test cases
+ revert jetty.sslContext.reload.followLinks boolean
+ Scanner should follow its own linkOptions setting
+ remove bad documentation in module-ssl-reload.adoc
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Co-authored-by: Lachlan Roberts <lachlan@webtide.com>
* Fixes#8863 - Provide a possibility to name virtual threads
Reworked the VirtualThreads APIs to be based on `Executor` rather than just `boolean`.
Introduced Jetty module `threadpool-virtual-preview`.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
* Issue #8716 - Handle bad host/authority headers better
* Remove extra `Host` header in testcase that doesn't deal with bad Host headers
* Create URIUtil.isRegName
* Correcting HostPortTest.testValidAuthority
* Correcting RequestTest.testInvalidHostHeader
* Remove clonable, set to final
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Updating to version 10.0.12
* Updating to version 10.0.13-SNAPSHOT
* VERSION.TXT =+ content of jetty-9.4.49.v20220914 release
* remove strange line and reorder
* Fixes#8532 - Review System.nanoTime() usages.
Introduced o.e.j.util.NanoTime class to deal with nanoTimes.
Now NanoTime.now() should be used instead of System.nanoTime(),
and various <unit>[elapsed|since|until]() methods to calculate nanoTimes.
Furthermore, comparing 2 nanoTimes should be done via isBefore(),
rather than using the < operator, which is wrong as specified in
the System.nanoTime() javadocs.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Now using Executors.newVirtualThreadPerTaskExecutor() to execute
tasks, so the executor is tracked by the runtime for thread dumps, etc.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Implemented support for virtual threads for HTTP/1.1, HTTP/2 and HTTP/3.
The virtual thread support is in AdaptiveExecutionStrategy.
When virtual threads are supported and enabled, reserved threads are disabled and
blocking tasks are run in a virtual thread instead that being executed by the Executor.
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
All `ByteBufferPool` can now be accessed as `RetainableByteBufferPools`.
Users now need to configure only a single buffer pool and there is just the additional retained parameter that needs consideration.
Default buffer pool has been changed to logarithmic, but we may wish to review that before next release.
Default factor size has been increased to 4096.
* Use StaticException class in jetty-util for websocket flushers.
* Use StaticException class for ContentProducer recycle and consumeAll
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Ludovic Orban <lorban@bitronix.be>
Co-authored-by: Ludovic Orban <lorban@bitronix.be>
* Bump jolokia-war from 1.3.3 to 1.7.1
Bumps jolokia-war from 1.3.3 to 1.7.1.
---
updated-dependencies:
- dependency-name: org.jolokia:jolokia-war
dependency-type: direct:production
update-type: version-update:semver-minor
...
* Adding HashLoginService to jolokia.xml
* Fixing typo in FQCN for Jetty Password utility
* Using logger to print warning, not ServletContext.log() as it causes an NPE.
Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
* Honor parameters order when parsing query and form parameters
When parsing the query or form parameters in Request, the values are stored in a MultiMap. This class extends HashMap which does not preserve the order of insertion so a request with parameters "first=1&second=2" might end up in a map where "second" will come first when iterating on the entry set.
The order is necessary in some case where the request is signed off the body and/or the query parameters. When the order is not preserved, it is impossible to reconstruct the original request sent, unless using the Request::getInputStream which consumes the stream and makes subsequent calls to Request::getParameters to don't return the form parameters which can be misleading. The same behavior applied to query parameters, by using Request::getQueryString, you get the correct order but Request::getParameters will not.
Moreoever, if the application is behind a reverse proxy using Jetty that is proxying using Request::getParameters which consume the request InputStream, it will be completely impossible to reconstruct the original request.
* Added a test with parameter merging
Co-authored-by: Jacques-Etienne Beaudet <jebeaudet@gmail.com>
dependabot[bot]
Simone Bordet
Olivier Lamy
gregw
Dominik Zöchbauer
Joakim Erdfelt
Lachlan
Olivier Lamy
Ludovic Orban