8 Replies Latest reply on Jun 6, 2003 6:18 PM by Ronald van Kuijk

    implementing retry timeout

    Ronald van Kuijk Newbie

      Hi,

      I'm working on a ebxml based messaging server that i'd like to run in Jboss.

      I'd like the outgoing queues to be JMS queues. Ebxml contains a timout parameter for retrying if the delivery fails. I know that thew JMS specs do not define this, but Bea as wel as IBM (afaik) have implemented a retry-timeout in their jms servers. This is very handy since I do not have to implement anythinh for this.

      Is there any change JBoss will support anything like this as well?

      tnx,
      Ronald

        • 1. Re: implementing retry timeout
          Ronald van Kuijk Newbie

          I've started implementing this. Currently i've added two header fields, jmsRedeliveryTimeout and jmsRedeliveyCount.

          In the receive method in BasicQueue i've added a check like 'mayDeliver()' which is implemented in SpyMessage and does this:


          public boolean mayRedeliver() {
          if (header.jmsRedeliveryTimeout ==0)
          return true;
          long ts = System.currentTimeMillis();
          return (header.jmsTimeStamp + header.jmsRedeliveryCount * header.jmsRedeliveryTimeout) - ts < 0;
          }



          Questions that remain:
          - should there be a provider wide configurable default?
          - should it be implemented using JMS_* properties instead of headers?
          - should there be a 'j2ee-comliancy switch' to disable all this?
          - ....

          Any comments?

          Ronald

          • 2. Re: implementing retry timeout
            Ronald van Kuijk Newbie

            ofcourse all the appropriate getters and setters, persitency etc.. is added as well.

            • 3. Re: implementing retry timeout
              Elias Ross Master


              I already checked in some code to CVS for these features.

              http://sourceforge.net/tracker/index.php?func=detail&aid=744455&group_id=22866&atid=381174


              Applied a patch which adds the following JBoss
              vendor-specific JMS properties:

              "JMS_JBOSS_SCHEDULED_DELIVERY";
              "JMS_JBOSS_REDELIVERY_DELAY";
              "JMS_JBOSS_REDELIVERY_COUNT";
              "JMS_JBOSS_REDELIVERY_LIMIT";

              1. Scheduled delivery, paused (delayed) re-delivery
              2. Track number of delivery attempts of a message
              3. Set maximum delivery attempts per message
              4. Proactively expire messages, without having to
              restore the whole message from disk if cached. Also, the
              same timer thread which handles scheduled messages proactively "reaps" expired messages.

              • 4. Re: implementing retry timeout
                Ronald van Kuijk Newbie

                great.... tnx, but is the functionality behind it also implemented?

                I'll try to do an update from cvs...

                At least for me it was a good start to get to know the jboss sourcecode and to me it was really clean and structured.

                Next excercise for me will be orderd delivery based on
                JMSXGroupID and JMSXGroupSeq (so ordered delivery within a JMSXGroupID, but not between messages with different JMSXGroupID's)



                • 5. Re: implementing retry timeout
                  Ronald van Kuijk Newbie

                  I've seen it is all implemented on the 3.2 branch... I'll check that one out later... But is my assumption right that for each message that is to be redelivered/scheduled a separate thread is started?

                  In our production environment that could easilly add up to 10.000 messages and thus 10.000 threads???

                  My implementation was checking on a receive whether a message is allowed to be redeliverd or ust has to wait a little more.

                  I don't know what the performance issue is in either case, but 10.000 threads seems a lot to me.

                  • 6. Re: implementing retry timeout
                    Raja Master

                    i have the same question as the prev poster.

                    If u are doing scheduled delivery, do yu start a different thread and sleep in that till the trigger happens? Is this scalable?
                    One option would be to serialize it till the trigger happens but the cost of Disk IO might be a factor here.

                    TIA
                    Raj

                    • 7. Re: implementing retry timeout
                      Elias Ross Master


                      I use a timer thread (look at java.util.Timer), so that all the scheduling happens in one thread per queue or topic. I don't need to have a thread per message.

                      • 8. Re: implementing retry timeout
                        Ronald van Kuijk Newbie

                        great to hear... I admit that I did not look into the implementation in detail and (shame on me) made the wrong assumption

                        Tnx again for implementing this.

                        Ronald