implementing retry timeout

[rtvkuijk]

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

[rtvkuijk]

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

[rtvkuijk]

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

[genman]

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.

[rtvkuijk]

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)

[rtvkuijk]

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.

[raja05]

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

[genman]

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.

[rtvkuijk]

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