Skip to main content

MDB and endpointExceptionRedeliveryAttempts + infinite redelivery loop

5 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
janne postilista

Hi,

 my MDB calls other (session) EJBs. In some cases, EJB call X fails,
sets transaction to rollback, and my MDB's onMessage ends normally (it
does not throw exceptions). In this case, I always get infinite loop
while my MDB retries the same message again and again. Setting
endpointExceptionRedeliveryAttempts to the MDB has no effect in this
case.

@MessageDriven(mappedName = "jms/test/zzz", activationConfig =  {
       @ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Queue"),
       @ActivationConfigProperty(propertyName =
"sendUndeliverableMsgsToDMQ", propertyValue = "true"),
       @ActivationConfigProperty(propertyName =
"endpointExceptionRedeliveryAttempts", propertyValue = "0")
})

=> infinite retries when transaction is set to rolled back but no
exception is thrown from onMessage.

QUESTION: is this as it should be? Is there some design rules which
says that "MDB should always throw (unchecked?) exception if
transaction fails"? Or should endpointExceptionRedeliveryAttempts
config also affect the cases when MDB does not throw exceptions (as I
would have thought)?

Of course, I can alter the design and even add

if (transaction.isRolledback()) {
 throw new NullPointerException("dummy exception to stop looping eternally");
}

to my MDB.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Nigel Deakin

janne postilista wrote, on 27/08/2010 08:38:
> Hi,
>
> my MDB calls other (session) EJBs. In some cases, EJB call X fails,
> sets transaction to rollback, and my MDB's onMessage ends normally (it
> does not throw exceptions). In this case, I always get infinite loop
> while my MDB retries the same message again and again. Setting
> endpointExceptionRedeliveryAttempts to the MDB has no effect in this
> case.
>
> @MessageDriven(mappedName = "jms/test/zzz", activationConfig = {
> @ActivationConfigProperty(propertyName = "destinationType",
> propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(propertyName =
> "sendUndeliverableMsgsToDMQ", propertyValue = "true"),
> @ActivationConfigProperty(propertyName =
> "endpointExceptionRedeliveryAttempts", propertyValue = "0")
> })
>
> => infinite retries when transaction is set to rolled back but no
> exception is thrown from onMessage.
>
> QUESTION: is this as it should be? Is there some design rules which
> says that "MDB should always throw (unchecked?) exception if
> transaction fails"? Or should endpointExceptionRedeliveryAttempts
> config also affect the cases when MDB does not throw exceptions (as I
> would have thought)?

According to the user guide, endpointExceptionRedeliveryAttempts defines the "Number of times to redeliver a
message when MDB throws an exception during message delivery". The default value is 6. So if no exception is thrown then
this property is not relevant.

Nigel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

janne postilista

So if transaction gets rolled back (for example by some other EJB that
is called from the MDB), but the exception gets swallowed somewhere
somehow, the MDB always gets stuck in an infinite retry loop? Is this
sensible / do other application servers do this too? Should I make
some specific configurations to the message queue or message server to
prevent this from happening?

On Fri, Aug 27, 2010 at 12:34 PM, Nigel Deakin wrote:
> janne postilista wrote, on 27/08/2010 08:38:
>>
>> Hi,
>>
>>  my MDB calls other (session) EJBs. In some cases, EJB call X fails,
>> sets transaction to rollback, and my MDB's onMessage ends normally (it
>> does not throw exceptions). In this case, I always get infinite loop
>> while my MDB retries the same message again and again. Setting
>> endpointExceptionRedeliveryAttempts to the MDB has no effect in this
>> case.
>>
>> @MessageDriven(mappedName = "jms/test/zzz", activationConfig =  {
>>        @ActivationConfigProperty(propertyName = "destinationType",
>> propertyValue = "javax.jms.Queue"),
>>        @ActivationConfigProperty(propertyName =
>> "sendUndeliverableMsgsToDMQ", propertyValue = "true"),
>>        @ActivationConfigProperty(propertyName =
>> "endpointExceptionRedeliveryAttempts", propertyValue = "0")
>> })
>>
>> =>  infinite retries when transaction is set to rolled back but no
>> exception is thrown from onMessage.
>>
>> QUESTION: is this as it should be? Is there some design rules which
>> says that "MDB should always throw (unchecked?) exception if
>> transaction fails"? Or should endpointExceptionRedeliveryAttempts
>> config also affect the cases when MDB does not throw exceptions (as I
>> would have thought)?
>
>
> According to the user guide, endpointExceptionRedeliveryAttempts defines the
> "Number of times to redeliver a
> message when MDB throws an exception during message delivery". The default
> value is 6. So if no exception is thrown then this property is not relevant.
>
> Nigel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

spmurphy
Offline
Joined: 2012-08-07
Points: 0

Hi, was there ever any resolution to this? I have the same problem and I'm using GF 3.1.2. thanks, Sean

spmurphy
Offline
Joined: 2012-08-07
Points: 0

is checking to see if the transaction is rolled back and then throwing a runtime exception the only way to go?