2 Replies Latest reply on May 6, 2013 3:49 PM by Marcin Nowrot

    Number of @Schedule method execution re-runs on exception

    Marcin Nowrot Newbie

      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.

        • 1. Re: Number of @Schedule method execution re-runs on exception
          Radim Hanus Expert

          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

          • 2. Re: Number of @Schedule method execution re-runs on exception
            Marcin Nowrot Newbie

            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