RediveryDelay implemented yet?

[cresny]

In our tests of JBoss Messaging 1.2.0.GA, RedeliveryDelay values are not having any effect, either in a Destination or when set as DefaultRedeliveryDelay in ServerPeer. The delay seems to remain at zero no matter what ms values are set.

Is there another api that affects/enables RedeliveryDelay?

[timfox]

Please can you post an example that does not work?

Also look at org.jboss.test.messaging.jms.ScheduledDeliveryTest for an example of redelivery working.

[parressh]

The RedeliveryDelay is not working for me either. I'm using JBoss Messaging 1.2.0SP1 deployed to JBoss 4.0.5.GA. My destination config looks like this:

 <mbean code="org.jboss.jms.server.destination.QueueService"
 name="jboss.messaging.destination:service=Queue,name=leadQueue"
 xmbean-dd="xmdesc/Queue-xmbean.xml">
 <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
 <depends>jboss.messaging:service=PostOffice</depends>
 <attribute name="RedeliveryDelay">300000</attribute>
 </mbean>

If I throw a RuntimeException in the MDB, then it retries it immediately multiple times until it eventually goes into the DLQ. It should wait 5 min between each attempt for this case, right?

Thanks

[timfox]

If you are using MDBs, then the MDB container lives between JBoss Messaging and your MDB.

So if your MDB throws an exception it is caught in the MDB container, which handles redelivery.

I don't believe the MDB container contains delayed redelivery functionality.

It may be possible to confgure the MDB container to not do redelivery and pass the exception back up , I need to check with Weston to see if it supports that.

[weston.price]

It may be possible to confgure the MDB container to not do redelivery and pass the exception back up , I need to check with Weston to see if it supports that.

No we don't.

We support catching the exception and taking the appropriate action based on transactional semantics.

We should probably support redelivery delay. I can file a JIRA.

[timfox]

This is an interesting one.

JBM implements a lot of nice functionality like delayed redelivery, DLQ configured on a per destination basis, Expiry queues configured on a per destination basis etc.

But when using MDBs these aren't used for the previously mentioned reasons. This seems a bit of a shame.

I guess it would be nice if the mdb container could be configured to delegate dlq, and expiry behaviour to the jms provider, since otherwise this functionality is unusable to the user if they are using MDBs.

[timfox]

Actually expiry behaviour should be ok, but anything that's triggered by throwing exceptions will be snagged by the MDB container before JBM has a chance to do anything

[weston.price]

This is an interesting one.

They all are :-)

The real question, and this is applicable for the expiration stuff as well, is what is the job of the container versus the provider. The JMS spec is pretty thin on what constitutes QOS. The JCA spec is equally reticient in terms of these types of services.

So, it's a matter of deciding who does what. Our clients don't care. The onus is on us to give them the best implementation we can. Pluggability in this regard is key IMO since all QOS stuff has a cost.

[parressh]

This is certainly becoming an interesting discussion! :) I guess I didn't realize that using an MDB would really change the semantics of how the JMS consumer (MDB) functions. Is my understanding correct that if the MDB throws an exception, the container does not ask for the message again, but simply retries the MDB? Like a for loop with a built-in number of iterations and hard-coded to send to the DLQ destination afterwards?

I agree that it would be really nice if the container could delegate those actions to the JMS container somehow, or maybe read in the JMS configs. Like Weston said, it probably doesn't matter how it gets done, but it would be nice as a customer to take advantage of the JBM feature set.

So, how would you (tim) recommend implementing a JMS consumer without MDB's inside of a web app? The web app is both sending and receiving the messages.

[timfox]

"parressh" wrote:

I agree that it would be really nice if the container could delegate those actions to the JMS container somehow, or maybe read in the JMS configs. Like Weston said, it probably doesn't matter how it gets done, but it would be nice as a customer to take advantage of the JBM feature set.

Actually, it was me who said that :)

[parressh]

Sorry, I'm not trying to misplace any praise. I was responding to Weston saying:

So, it's a matter of deciding who does what. Our clients don't care.

I think both of you are making valid points, and it's good to see you both seem to be on the same page. I just hope it's feasible to work something out here.

Anyway, how can I get around this now? Any alternative to MDB that you suggest? Or perhaps a workaround with MDB?

[timfox]

I don't see there is much you can do about this.

Since the MDB container comes between JBM and the MDB there is no opportunity for JBM to do anything here.

What I don't undertsand is what you are doing with MDBs inside your web app.

[cresny]

"timfox" wrote:
If you are using MDBs, then the MDB container lives between JBoss Messaging and your MDB.

So if your MDB throws an exception it is caught in the MDB container, which handles redelivery.

I don't believe the MDB container contains delayed redelivery functionality.

It may be possible to confgure the MDB container to not do redelivery and pass the exception back up , I need to check with Weston to see if it supports that.

I don't see how this is the case. The queues have almost the exact configuration with JBossMQ, and the redelivery delay works perfectly in JbossMQ using same MDB container. Also, I assumed the MDB Container would simply rethrow the mdb exception and let the TransactionManager sort it out.

[timfox]

Cresny-

If you post a code example that demontrates redelivery delay working on JBoss MQ, but not on JBM I will investigate.

Best to open a JIRA task and post it against that.

[cresny]

Tim,

There is no code example, just the MBean queue configuration that parressh has already provided.

The integration test would be to use parressh's config and throw a runtime exception from a container-managed MDB listening on the queue. With JBossMQ, the message would be redelivered five minutes later.

If it hasn't already been done, I will file a JIRA today.