0

There are 10 scheduler of this type in same Class file:

@Startup
@Singleton
@AccessTimeout(value = 1, unit = TimeUnit.HOURS)
public class MeowPoller {

    @Schedule(hour = "02", minute = "00", persistent = false)
    public void runFetchApplications() {

When some job stuck for say 3 hours then next job does not execute till this job finish.

System keeps on giving:

2020-01-20 01:02:00,001 WARN  [org.jboss.as.ejb3.timer] (EJB default - 6) WFLYEJB0043: A previous execution of 
timer [id=459875b7-5346-40c1-a9a0-f36dec8ef53d timedObjectId=Meow-1.6-SNAPSHOT.Meow-1.6-SNAPSHOT.MeowPoller 
auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@7ffe6c6a 
initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Jan 20 01:02:00 CET 2020 timerState=IN_TIMEOUT 
info=null] is still in progress, skipping this overlapping scheduled execution at: Mon Jan 20 01:02:00 CET 2020.
fatherazrael
  • 5,511
  • 16
  • 71
  • 155
  • It is fine to have multiple ejb schedulers in your bean. Singleton is however not shared by default. if your singleton is thread-safe, you may annotate the scheduled methods with `@Lock(READ)` to make the EJB shared by different threads (default value is `@Lock(WRITE)`. See also [here](https://docs.oracle.com/javaee/7/tutorial/ejb-basicexamples002.htm#GIPVI) – Lini Jan 23 '20 at 15:32
  • @Lini: No all methods are EJB schedulers and shall be executed at given time so it should not require @Lock(Read) and by default @Lock(Write) should work. The warning given is genuine i think? It says that times is in progress and next scheduled time comes so have chill. Any idea to ignore this warning? – fatherazrael Jan 24 '20 at 05:07
  • The warning is for your information that the execution takes longer than you would expect. I stil think you need `@Lock(READ)` on your scheduled methods, otherwise no scheduled method can be invoked if one of them is in progress. Because your singleton is invoked by scheduler threads. You can simulate this bahavior easily and then add `@Lock(READ)` to see the difference. Regarding the execution time, it it takes that long, I would consider do it asynchronously so your scheduled methods do not block, but be careful you may run out of threads if multiple method executions run concurrently. – Lini Jan 24 '20 at 23:09

0 Answers0