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

@Scheduled annotation should support property placeholder values [SPR-6670] #11336

Closed
spring-projects-issues opened this issue Jan 11, 2010 · 2 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jan 11, 2010

Mark Fisher opened SPR-6670 and commented

This would promote externalization of the actual scheduling configuration.

Rather than:

@Scheduled(cron = "0 0 9-17 * * MON-FRI")
public void doSomething() {...}

The cron expression could be in a properties file, so the annotation no longer contains a hard-coded value:

@Scheduled("${schedules.businessHours}")
public void doSomething() {...}

This should also work with meta-annotations, e.g.:

@Scheduled(cron = "${schedules.businessHours}")
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)	
public @interface BusinessHours {}

...would apply to:

@BusinessHours
public void doSomething() {...}

Affects: 3.0 GA

Issue Links:

Referenced from: commits 410dd0a

@spring-projects-issues
Copy link
Collaborator Author

Flemming Jønsson commented

The support for property placeholder values only goes for the cron (String) parameter. Is there any chance this could be extended to also be possible for fixedDelay and fixedRate (both of type long).

@spring-projects-issues
Copy link
Collaborator Author

Mark Fisher commented

Since fixedDelay and fixedRate are of type long, they cannot accept a String value. Therefore, we cannot provide support for property placeholders since that would require actually providing String values in the annotation. The only option would be to add further String-typed attributes specifically for that purpose, but it seems like that could lead to confusion. When using the XML support via <scheduled-tasks>, property placeholders can be used even for the fixed-delay and fixed-rate, because the extra processing step of XML parsing is always dealing with text anyways. It's unfortunately not that simple with the annotation support.

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.0.1 milestone Jan 11, 2019
okotsopoulos added a commit to DataBiosphere/jade-data-repo that referenced this issue Mar 9, 2023
This later version will allow us to use property placeholders to set @scheduled cron schedules.
See spring-projects/spring-framework#11336
okotsopoulos added a commit to DataBiosphere/jade-data-repo that referenced this issue Mar 15, 2023
* [DR-2843] Upgrade to Spring Boot 3.0.4

This later version will allow us to use property placeholders to set @scheduled cron schedules.
See spring-projects/spring-framework#11336

* [DR-2843] Configure ShedLock distributed lock for Spring @scheduled tasks

- Add JDBC-powered ShedLock latest releases to build dependencies
- Create datarepo.shedlock table for storing distributed lock: name and schema are dictated by ShedLock README
- Configure a JDBC ShedLock LockProvider: tells ShedLock to use our Postgres DB and its clock for managing locks

* Increase Spring @scheduled pool size from default 1 -> 10

* Make DUOS group sync a Spring @scheduled task

- By default, this cron is disabled: set DUOS_SYNCUSERS_SCHEDULE env var to a valid cron expression to schedule
- Manage distributed lock with ShedLock:
  - Minimally hold the lock for 5 seconds (this helps protect against node clock differences for short-running tasks)
  - We expect this task to take a few seconds
  - As a fallback in case the locking node dies, maximally hold the lock for 5 minutes (much longer than expected execution time)
Caveat: the lock will be unconditionally removed if present at the end of its maximum lock time, even if the task is still executing.
In this case the possibility of this happening and the risk if it does are low enough as to not warrant adding further complexity.
ShedLock also offers a KeepAliveLockProvider but advises its use only if necessary: https://github.com/lukas-krecan/ShedLock#keepalivelockprovider

* Add README for @scheduled ShedLock tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant