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.

=> 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)?

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.

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
>
>