Problems with MaxDeliveryAttempts

[noxis]

With JBM 1.4.0.CR1 MaxDeliveryAttempts works fine with my MDB.
Since 1.4.0.CR2 (CR3, GA, trunk) I have to set DLQMaxResent in MDB, because MaxDeliveryAttempts is ignored. I can also see this message after redelivery:

2007-10-25 15:49:37,118 WARN [org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler] Message redelivered=6 max=5 sending it to the dlq delegator->JBossMessage[2]:PERSISTENT, deliveryId=7

Queue configuration:

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

Is this expected behaviour since 1.4.0.CR2?

I have found that this behaviour was introduced by commit:
"Fix on JMSXDeliveryCount" date: 2007-08-01, revision: 2943

BTW. As you can see in my config, I am trying to do infinite redelivery by pointing DLQ to the same queue. Is this ok? Maybe there is a better solution?

[timfox]

What's max delivery attempts set to in your MDB container config?

[noxis]

"timfox" wrote:
What's max delivery attempts set to in your MDB container config?

It's a default value on JBAS 4.2.1.GA. If you need an exact value, I can give it to you in 2 weeks (I am on vacation:)).

I think I have to clarify my last post.

- JBM 1.4.0.CR1 with MaxDeliveryAttempts=10: OK

- JBM 1.4.0.CR2 (CR3, GA, trunk) with MaxDeliveryAttempts=10:

2007-10-25 15:49:37,118 WARN [org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler] Message redelivered=6 max=5 sending it to the dlq delegator->JBossMessage[2]:PERSISTENT, deliveryId=7

- JBM 1.4.0.CR2 (CR3, GA, trunk) with DLQMaxResent=10: OK

- JBM 1.4.0.CR2 (CR3, GA, trunk) with MaxDeliveryAttempts=10,
and 1 patch reverted - "Fix on JMSXDeliveryCount": OK

So, MaxDeliveryAttempts stopped to work with MDBs with that patch. Bug or feature?

[timfox]

The AS JCA layer also has it's own redelivery logic (this is the one that's controlled by DLQMaxResent) - this is so that JCA layer can be used consistently with a range of different JMS providers who may not have their own redelivery or DLQ functionality.

JBM also has it's own DLQ and redelivery functionality.

By default I believe the JCA redelivery will take precedence over JBM delivery. I beieve the JCA default is 5 - this would make sense with what you're seeing.

I would say the current behaviour is now correct. Previously before Clebert's patch the JMSXDeliveryCount property wasn't be stored properly in the message hence the JCA layer didn't know the messages delivery count and the JCA delivery did not kick in.

If you don't want the JCA delivery you can turn it off in the config, and just use the JBM one.

[timfox]

"noxis" wrote:

BTW. As you can see in my config, I am trying to do infinite redelivery by pointing DLQ to the same queue. Is this ok? Maybe there is a better solution?

You could just set maxDeliveryAttempts to a very large value.

Pointing the DLQ to the same queue would mean the message is put to the *back* of the queue when maxDeliveryAttempts is exceeded

We could add a feature to explicitly allow infinite redelivery. You could add a JIRA task if you like.