[Use Case]: More Control on Scheduled

[hantsy]

As a ...

• Application user/user of the configuration itself
• API user (application developer)
• SPI user (container or runtime developer)
• Specification implementer

I need to be able to ...

The @Asynchronous(runAt=) lacks several features from the existing Spring and EJB.

Which enables me to ...

Add the following attributes to the @Scheduled annotations.

1. initial delay
2. fixed delay between intervals
3. if start the next running when the last running is not finished
4. Only run once.
5. @Timeout replacement from EJB

Additional information

• https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/scheduling/annotation/Scheduled.html
• https://docs.oracle.com/javaee/6/api/javax/ejb/Timeout.html

[njr-11]

4. Only run once.

The current API already offers this. The first paragraph of the Javadoc for runAt states: "The Jakarta EE product attempts to run the method at the scheduled times until its future is completed or the method returns a non-null result value or raises an exception." The asynchronous method can choose any of these 3 ways to make itself only run once.

5. @Timeout replacement from EJB

The aspect that we are aware of that is still needed is to automatically submit/schedule the asynchronous method upon application startup. We have issue #624 to add that. If there is some other capability that you are aware of that is lacking, or if you were asking for other capability of EJB timers that we don't have in Jakarta Concurrency like persistent timers, please be specific about identifying what it is. Otherwise, I will assume 624 adequately covers this requirement.

3. if start the next running when the last running is not finished

This is very poorly written, so I can only guess what you are proposing. Are you asking to have overlapping executions of the same asynchronous method such that if one method is scheduled to run every 5 seconds and the first execution takes 18 seconds and the second execution takes 8 seconds, then the first, second, and third executions will all be running at the same time? This would burden the application with needing to write the asynchronous method in a way that is tolerant of overlapping execution. The Concurrency specification has always tried to avoid that sort of usage, and I am unaware of any important use cases that would justify us adding in that complexity, so currently I would vote against this and would need a lot of convincing why it is a good idea.

1. initial delay
2. fixed delay between intervals

ManagedScheduledExecutorService already has initial delay, and fixed delay, (as well as another option called fixed rate, and also the ability to provide custom business logic for computing delays). This capability is used programmatically rather than via the Asynchronous annotation. Do you have an important use case behind why an application needs to be able to specify these delays on Asynchronous rather than programmatically as is currently possible? And if so, why fixed delay vs the other patterns like fixed rate or custom delays?

[hantsy]

Do you have an important use case behind why an application needs to be able to specify these delays on Asynchronous rather than programmatically as is currently possible? And if so, why fixed delay vs the other patterns like fixed rate or custom delays?

I hope the annotations declaration in our spec has equivalent programmatic approaches, and implements the same features.

This means more options for end users. Finally, we can select creating a Jakarta EE application using a functional programming model or by annotation declaration.

[hantsy]

Are you asking to have overlapping executions of the same asynchronous method such that if one method is scheduled to run every 5 seconds and the first execution takes 18 seconds and the second execution takes 8 seconds, then the first, second, and third executions will all be running at the same time?

yes, hope there are some options for users to select

• run as scheduled and allow them to be executed in parallel
• wait for previous is completed(done or exception) and run in queue
• Skip running the next task if the previous task is not finished.