Fix Resource Leak In Jetty #4783
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We had a resource leak in Jetty due to us not calling `.destroy` in the `def resource` after the server terminated. Fixing this leak was a bit complicated. By default, Jetty will terminate the provided `ThreadPool` as part of the resource cleanup in `.destroy`. Since we were sharing the `ThreadPool` in the builder, this would cause any new invocations of `def resource` to fail as the underlying `ThreadPool` will have now been terminated. To fix this problem we now use a `Resource[F, ThreadPool]` which will ensure that we get a fresh `ThreadPool` on each invocation, as well as ensuring proper shutdown semantics. We have to keep around the old `ThreadPool` for binary compatibility. In order to avoid starting _two_ `ThreadPool` instances we introduce a `LazyThreadPool` which _should_ never actually create a `ThreadPool` (I had to leave some `ThreadPool` type here and I didn't want to use `null` or anything that would throw if it got accidentally accessed). If someone explicitly sets the `ThreadPool` with the deprecated `withThreadPool` method, then we wrap it in `UndestroyableThreadPool` which hides the `join` method and thus preserves the old behavior allowing the `ThreadPool` to be shared across multiple invocations of `def resource` while still allowing us to cleanup all the other resources. `JettyLifeCycle` provides utilities which lift the Jetty interfaces `LifeCycle` and `Destroyable` into a `Resource`. These are not public to keep the binary compatibility surface as small as possible. In order to allow users to customize the `ThreadPool` a subset of `JettyLifeCycle` is exposed in `JettyThreadPools`.
hamnis
approved these changes
May 5, 2021
|
needs a conflict resolving, otherwise good |
|
@hamnis conflicts are resolved. Thanks for the review! |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We had a resource leak in Jetty due to us not calling
.destroyin thedef resourceafter the server terminated. Fixing this leak was a bit complicated.By default, Jetty will terminate the provided
ThreadPoolas part of the resource cleanup in.destroy. Since we were sharing theThreadPoolin the builder, this would cause any new invocations ofdef resourceto fail as the underlyingThreadPoolwill have now been terminated.To fix this problem we now use a
Resource[F, ThreadPool]which will ensure that we get a freshThreadPoolon each invocation, as well as ensuring proper shutdown semantics. We have to keep around the oldThreadPoolfor binary compatibility. In order to avoid starting twoThreadPoolinstances we introduce aLazyThreadPoolwhich should never actually create aThreadPool(I had to leave someThreadPooltype here and I didn't want to usenullor anything that would throw if it got accidentally accessed).If someone explicitly sets the
ThreadPoolwith the deprecatedwithThreadPoolmethod, then we wrap it inUndestroyableThreadPoolwhich hides thejoinmethod and thus preserves the old behavior allowing theThreadPoolto be shared across multiple invocations ofdef resourcewhile still allowing us to cleanup all the other resources.JettyLifeCycleprovides utilities which lift the Jetty interfacesLifeCycleandDestroyableinto aResource. These are not public to keep the binary compatibility surface as small as possible. In order to allow users to customize theThreadPoola subset ofJettyLifeCycleis exposed inJettyThreadPools.