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.

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 simplified API for wrapping scheduled tasks. #1546

Merged
merged 8 commits into from Mar 28, 2019
Merged

Conversation

bsideup
Copy link
Contributor

@bsideup bsideup commented Feb 26, 2019

Schedulers.onScheduleHook(String, Function<Runnable,Runnable>) is a new
API for wrapping the tasks submitted to Reactor's schedulers.

@bsideup bsideup added the type/enhancement A general enhancement label Feb 26, 2019
@bsideup bsideup added this to the 3.3.0.RELEASE milestone Feb 26, 2019
@codecov-io
Copy link

codecov-io commented Feb 27, 2019

Codecov Report

Merging #1546 into master will increase coverage by 0.13%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1546      +/-   ##
============================================
+ Coverage      84.2%   84.33%   +0.13%     
- Complexity     3907     3918      +11     
============================================
  Files           359      359              
  Lines         29920    29958      +38     
  Branches       5566     5574       +8     
============================================
+ Hits          25194    25265      +71     
+ Misses         3096     3075      -21     
+ Partials       1630     1618      -12
Impacted Files Coverage Δ Complexity Δ
...re/src/main/java/reactor/core/publisher/Hooks.java 96.31% <ø> (ø) 41 <0> (ø) ⬇️
...c/main/java/reactor/core/scheduler/Schedulers.java 85.71% <100%> (+2.62%) 83 <23> (+10) ⬆️
...rc/main/java/reactor/core/publisher/Operators.java 79.49% <0%> (+0.14%) 123% <0%> (ø) ⬇️
...ain/java/reactor/core/publisher/FluxPublishOn.java 86.8% <0%> (+0.2%) 6% <0%> (ø) ⬇️
...ain/java/reactor/core/publisher/FluxConcatMap.java 90.42% <0%> (+0.28%) 7% <0%> (ø) ⬇️
...va/reactor/core/publisher/FluxMergeSequential.java 82.75% <0%> (+0.38%) 6% <0%> (ø) ⬇️
...eactor/core/publisher/ParallelMergeSequential.java 80.31% <0%> (+0.51%) 7% <0%> (ø) ⬇️
...in/java/reactor/core/publisher/TopicProcessor.java 74.85% <0%> (+0.59%) 16% <0%> (ø) ⬇️
...c/main/java/reactor/core/publisher/FluxReplay.java 84.78% <0%> (+0.62%) 25% <0%> (ø) ⬇️
...java/reactor/core/scheduler/ExecutorScheduler.java 79.86% <0%> (+0.69%) 12% <0%> (ø) ⬇️
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e8c8a1c...9a4cb12. Read the comment docs.

public <V> ScheduledFuture<V> schedule(Callable<V> callable,
long delay,
TimeUnit unit) {
return (ScheduledFuture<V>) delegate.schedule(wrap(callable), delay, unit); //FIXME
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsideup @smaldini I can see why the new interface was proposed to map both Runnable and Callable. Maybe instead of hard casting we should throw UOE, saying that reactor internals are not supposed to call ScheduledExecutorService Callable-based methods?

And probably hunt down every place where we have access to an executor to introduce a comment that such executors' Callable-based methods are off limits?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we leak the ScheduledExecutorService to our public API, these UOE make me feel uneasy to be honest. Did you come to some agreement with @smaldini about this?


@Override
public <T> Future<T> submit(Callable<T> task) {
return (Future<T>) delegate.submit(wrap(task)); //FIXME
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here as FIXME above

* @see #resetOnSchedule(String)
* @see #resetOnSchedule()
*/
public static void onSchedule(String key, Function<Runnable, Runnable> decorator) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsideup I aligned the naming of the method and its behavior with other hooks. Main change is that it is now "add or replace" (put). Unless there is a compelling reason for this particular hook to be putIfAbsent unlike the others?

* This key is used to add the {@link #onSchedule(String, Function)} composite hook as
* a {@link Schedulers#addExecutorServiceDecorator(String, BiFunction) executorService decorator}.
*/
private static final String EXECUTOR_DECORATOR_ONSCHEDULE = "reactor.onSchedule";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsideup I changed the constant name a bit and made it private because other constants at this level are used for storing a hook override in the Context (hence the .local suffix). This is different though: a key for the Schedulers own "hook" (the executor decorator).

@@ -70,7 +70,7 @@ public Void call() {
try {
try {
task.run();
setRest(executor.submit(this));
setRest(executor.submit((Callable<Void>) this));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this cast to Runnable instead? (see discussion in the HookableScheduledExecutorService)

Runnable is the only type that is guaranteed to be maintained by the Function<Runnable, Runnable>... Callable is used internally mostly for short-circuiting subscription IIRC, but I don't think they've been actively used for tasks scheduling purposes so far.

Having this new hook kind of enforces us to limit our use of ExecutorService to Runnable-based methods... cc @smaldini

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it to align with the rest of tasks. AFAIR the problem is that ScheduledThreadPoolExecutor wraps Runnable into Callable when submitted:
https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/classes/java/util/concurrent/FutureTask.java#L152

@bsideup bsideup requested a review from simonbasle March 22, 2019 12:17
@bsideup bsideup dismissed simonbasle’s stale review March 22, 2019 12:18

changed the implementation

bsideup and others added 8 commits March 27, 2019 15:11
`Hooks.addOnScheduleDecorator(String, ScheduledTaskDecorator)` is a new
API for wrapping the tasks submitted to Reactor's schedulers.

It's implemented as a "sugar" for `addExecutorServiceDecorator`,
but instead of registering a decorator per hook, we register a single
decorator and iterate over the registered `ScheduledTaskDecorator`s.
 - NotNull (from jetbrains) is not necessary. superseded by NonNullApi
  (from reactor) at package level anyway.
 - removed unused throws clauses for methods that throw UOE anyway
 - Reworked the hook naming and javadoc to reflect what we have with
 other transformative keyed hooks (onSchedule, resetOnSchedule(String)
 and resetOnSchedule()). onSchedule adding is now replacing decorators
 if a key exists.
@bsideup bsideup merged commit 98bda90 into master Mar 28, 2019
@bsideup bsideup deleted the on_schedule_decorator branch March 28, 2019 20:08
@bsideup bsideup mentioned this pull request Apr 9, 2019
@simonbasle simonbasle modified the milestones: 3.3.0.RELEASE, 3.3.0.M1 Apr 15, 2019
OlegDokuka pushed a commit to OlegDokuka/reactor-core that referenced this pull request Apr 24, 2019
`Schedulers.onScheduleHook(String, Function<Runnable,Runnable>)` is a new
API for wrapping the tasks submitted to Reactor's schedulers.

The hooks intercepts `Runnable`s before they passed to the executor.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants