Number of @Schedule method execution re-runs on exception

[draken123]

Hi All,

is it possible to configure the number of retries JBoss is attempting to do when an exception is thrown within a method annotated with @Schedule? As far as I was able to observe, the default is 1 retry, and I'd like to configure JBoss so it's 0.

Thanks and Best Regards,

draken123

00:30:03,097 INFO  [org.jboss.as.ejb3] (EJB default - 7) JBAS014121: Timer: [id=25e2fb5c-9062-49d4-aebf-11be92feda52 timedObjectId=myPkg.myPkg.MyTimerService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@1e14ce7 initialExpiration=Mon Apr 29 00:30:00 CEST 2013 intervalDuration(in milli sec)=0 nextExpiration=Sat May 04 00:30:00 CEST 2013 timerState=IN_TIMEOUT will be retried
00:30:03,097 INFO  [org.jboss.as.ejb3] (EJB default - 7) JBAS014123: Retrying timeout for timer: [id=25e2fb5c-9062-49d4-aebf-11be92feda52 timedObjectId=myPkg.myPkg.MyTimerService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@1e14ce7 initialExpiration=Mon Apr 29 00:30:00 CEST 2013 intervalDuration(in milli sec)=0 nextExpiration=Sat May 04 00:30:00 CEST 2013 timerState=IN_TIMEOUT

PS. The work-around is to move all code that is inside the @Schedule annotated method into an @Asynchronous method located in a different EJB class, and of course, call the new method from the @Schedule annotated method.

[rhanus]

EJB 3.1 spec: 18.4.3 Timer Expiration and Timeout Callback Method

"If container-managed transaction demarcation is used and the REQUIRED or REQUIRES_NEW transaction attribute is specified or defaulted (Required or RequiresNew if the deployment descriptor is used), the container must begin a new transaction prior to invoking the timeout callback method. If the transaction fails or is rolled back, the container must retry the timeout at least once."

you shouldn't be able to refuse the retry by setting a configuration option

on the other hand catching exception a setting rollback only doesn't help because:

"If the Bean Provider invokes the setRollbackOnly method from within the timeout callback method, the container must rollback the transaction in which the timeout callback method is invoked. This has the effect of rescinding the timer expiration. The container must retry the timeout after the transaction rollback."

simply catch runtime exceptions and provide some recovery if possible and return from timeout callback method

[draken123]

Dear Radim,

thanks for a detailed explanation. Now I at least know why the method was re-run on exception.

Radim Hanus wrote:

(...)

simply catch runtime exceptions and provide some recovery if possible and return from timeout callback method

I was doing the above in my code - I was catching all exceptions (runtime and checked alike) and then I was sending an email (from the catch block) to my own address, so I knew that something went wrong. The only problem was, that if something was wrong, I was getting the email twice, due to the original transaction being rolled back and the container retrying the timeout.

Best Regards,

Marcin