Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Consider more specific contract around Scheduler#start() #3202

Closed
chemicL opened this issue Sep 26, 2022 · 0 comments
Closed

Consider more specific contract around Scheduler#start() #3202

chemicL opened this issue Sep 26, 2022 · 0 comments
Assignees
@chemicL
Labels
type/enhancement A general enhancement warn/behavior-change Breaking change of publicly advertised behavior
Milestone
3.4.25

Comments

@chemicL
Copy link
Member

chemicL commented Sep 26, 2022

The inner workings of some Scheduler#start() consider the possibility to dispose() and then start() the same instance again. There are a few issues due to it:

  • More complex implementations around possibility of concurrent calls.
  • No consistency - some Schedulers allow restarts, while others don't.
  • API evolution is more difficult - the possibility of a restart makes reasoning around dispose() and the state after the call quite difficult - the only possibility to find out reliably if the Scheduler is disposed is to use disposeGracefully() and subscribe to the returned Mono. Any call to isDisposed() might be unreliable as there might have been concurrent restarts.

Unless there is a need for the restart capabilities, the contract could be tightened and a disposed Scheduler would prohibit further start() calls.
@chemicL chemicL added type/enhancement A general enhancement warn/behavior-change Breaking change of publicly advertised behavior labels Sep 26, 2022
@chemicL chemicL self-assigned this Sep 26, 2022
chemicL added a commit that referenced this issue Oct 18, 2022
@chemicL
Deprecating Scheduler#start() method
73a07ac 
Due to dangers associated with concurrent use of `start()` interleaved
with `dispose()` or `disposeGracefully()` to support restart capability
in some `Scheduler`s and the unreliability of `isDisposed()` in such scenarios,
the `start()` method is now deprecated in favor of a more well defined
`init()` method.

Resolves #3202.
@chemicL chemicL mentioned this issue Oct 18, 2022
Merged
@chemicL chemicL mentioned this issue Oct 21, 2022
Open
@chemicL chemicL modified the milestones: 3.5.0 planning, 3.4.25 Oct 21, 2022
chemicL added a commit that referenced this issue Mar 7, 2023
@chemicL
Deprecating Scheduler#start() method(#3236)
0da968f 
Due to dangers associated with concurrent use of `start()` interleaved
with `dispose()` or `disposeGracefully()` to support restart capability
in some `Scheduler`s and the unreliability of `isDisposed()` in such scenarios,
the `start()` method is now deprecated in favor of a more well defined
`init()` method.

Resolves #3202.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@chemicL chemicL

Labels
type/enhancement A general enhancement warn/behavior-change Breaking change of publicly advertised behavior
Projects
None yet
Milestone
3.4.25
Development

No branches or pull requests
1 participant
@chemicL