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.
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
Add disposeGracefully method to Scheduler #3089
Add disposeGracefully method to Scheduler #3089
Changes from 8 commits
44f5f2e
6fbd57c
a4a5b0e
13c020f
92f18b8
9026186
0084749
0f2684c
3ed8ad3
d1af720
0e801f0
d10d98a
52f1cf0
b0fc331
5703eb8
8b4bc63
7a0452f
3dc8dca
8399b5b
9f5a7eb
8dd4afb
2d2aa4e
bd03603
298c051
5e72d2e
255878f
cbe6663
6690a91
fcc5079
162cf2a
709f385
cb8373c
055f72c
c0c1eab
c4a5a99
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the semantics of disposeGracefully may vary widely, so I would make the documented contract say that explicitly (eg. "each class implementing this trait should define how subsequent calls behave during the grace period and after it")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one limitation I'm thinking of with this API is that most of the time the underlying resource(s) being disposed gracefully will be atomically swapped out. Which means that even if one re-subscribes to the
Mono
, including withonErrorResume()
orretry()
, the underlying resources won't be reachable anymore.thus, there will be no way of composing operators to fall back to a "hard" shutdown once the graceful shutdown is initiated.
I'm thinking this is fine if documented. The recommendation for implementors should probably be to trigger a hard dispose at the end of the
gracePeriod
THEN propagate aTimeoutException
, noting that it only serves as a warning / logging but cannot be recovered.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed the possible contracts here with @OlegDokuka. The approach with forceful shutdown before propagating the
TimeoutException
and non-recoverable errors might be confusing to users if they don't read the specificScheduler
documentation, but it has some advantages implementation wise.Another approach could be to propagate a retry-able error and allow re-initiating the
shutdown()
+awaitTermination(...)
procedure, while also allowing for an explicit final call to explicitshutdownNow()
when desired. I'll go back to the original issue and ask for opinion from the user's perspective to guide the design.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My personal opinion is that once we fix specific behavior (e.g. call
shutdownNow()
if a timeout orInteruptedException
) then we probably will end up with everyone doingscheduler.disposeGracefully(Duration.ofHours(9999999)).subscribe()
or then complaining that they did not wont to haveshutdownNow
called but rather retry laterAnother thought on
TimoutException
- any exception is useless if we can not do anything useful after that. I'm not sure that logging such an event makes any sense. This exception is just a fact that we forced shutdown process so a user just has to take it. Also, taking into account the impl details - all other active subscribers are going to get the same notification but the other late subscriber will not get it, then it is going to be too confusing so even having it documented will not resolve this confusion.My personal recommendation is to prefer flexibility over fixed behavior. One can always write something like the following to mimic what we can hardcode