Closed alvasw closed 10 months ago
@jmacxx Could you test this PR?
The Timer
documentation says that it will try to catch up on missed executions. Let's say a task takes usually 1 second to complete and for some reason it takes 30 seconds once. If we schedule the Timer
to run the ask every 10 seconds, the task will be called three times to catch up.
JDK Timer.scheduleAtFixedRate
documentation:
"In fixed-rate execution, each execution is scheduled relative to the scheduled execution time of the initial execution. If an execution is delayed for any reason (such as garbage collection or other background activity), two or more executions will occur in rapid succession to "catch up." In the long run, the frequency of execution will be exactly the reciprocal of the specified period (assuming the system clock underlying Object.wait(long) is accurate). [...]"
However I don't think that this PR will fix the bug in #33 .
Looking at it from another angle, pricenode provider has an entry point from [SpringBoot start()](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/Lifecycle.html#start()). What if SpringBoot invokes this more than once, from different threads? That could cause a problem as there's currently no guard against that.
void start() Start this component. Should not throw an exception if the component is already running.
If you would adapt this PR to guard against re-entrancy from SpringBoot, I think it would be better.
@alvasw Are you still working on this PR?
I'm closing this PR for now.
Related to #33