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 <nigel.deakin_at_oracle.com> 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_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>