5 Replies Latest reply on Mar 16, 2010 5:01 PM by andy.miller

    Configuring the EJB timer service

    andy.miller
      If I don't want failed EJB 3 timers to retry, can I just comment out the RetryPolicy attribute in the xml file?
        • 1. Re: Configuring the EJB timer service
          jaikiran

          A quick look at the code suggests that commenting out the retry policy is going to cause errors. It expects RetryPolicy as mandatory. I don't see any NoOpRetryPolicy available. So maybe the user application has to create a NoOpRetryPolicy and configure the timer service to use this.

          1 of 1 people found this helpful
          • 2. Re: Configuring the EJB timer service
            andy.miller

            jaikiran wrote:

             

            A quick look at the code suggests that commenting out the retry policy is going to cause errors. It expects RetryPolicy as mandatory. I don't see any NoOpRetryPolicy available. So maybe the user application has to create a NoOpRetryPolicy and configure the timer service to use this.

            I was starting to think that.  I'll probably implement a NoRetryPolicy and configure that, and test it out.  Thanks.

            • 3. Re: Configuring the EJB timer service
              andy.miller

              jaikiran wrote:

               

              A quick look at the code suggests that commenting out the retry policy is going to cause errors. It expects RetryPolicy as mandatory. I don't see any NoOpRetryPolicy available. So maybe the user application has to create a NoOpRetryPolicy and configure the timer service to use this.

              Well, I created a NoRetryPolicy class and MBean, patterned after the FixedDelayRetryPolicy, and it works as expected.  The issue that this brings up in my mind is that this seems to be global.  You can only have one retry policy defined.  Am I right about that?  Is there a way to make it so some timers use one retry policy and others use another?

              • 4. Re: Configuring the EJB timer service
                jaikiran

                andy.miller@jboss.com wrote:

                The issue that this brings up in my mind is that this seems to be global.  You can only have one retry policy defined.  Am I right about that?

                Yes right now it's a global timer service level retry policy.

                 

                andy.miller@jboss.com wrote:

                Is there a way to make it so some timers use one retry policy and others use another?

                I am not sure whether adding a retry policy per timer is appropriate. I'll read the specs for some details around this and update this thread.

                1 of 1 people found this helpful
                • 5. Re: Configuring the EJB timer service
                  andy.miller

                  jaikiran wrote:

                   

                  andy.miller@jboss.com wrote:

                  The issue that this brings up in my mind is that this seems to be global.  You can only have one retry policy defined.  Am I right about that?

                  Yes right now it's a global timer service level retry policy.

                   

                  andy.miller@jboss.com wrote:

                  Is there a way to make it so some timers use one retry policy and others use another?

                  I am not sure whether adding a retry policy per timer is appropriate. I'll read the specs for some details around this and update this thread.

                  I'm not sure about the specification, and I know EJB timers are changing quite a bit in EJB 3.1 (finally), but its very impractical to think that all EJB timers should be treated the same.  However, it doesn't appear that there is a way to do anthing but a global policy.  So, if you have this situation, where you want to do something different with different timers, you will have to break up the application into multiple instances of the server, which may not be practical.  This is probably something to think about in the new EJB 3.1 stuff, then the old EJB 3 (which is just the same EJB 2.x stuff anyway).