users@glassfish.java.net

Re: JMS exception causing resending message :(

From: Felipe Gaścho <fgaucho_at_gmail.com>
Date: Wed, 23 Sep 2009 09:24:46 +0200

finally I understood the problem..

Marina was right, I need to declare requiresNew transaction in the
sub-transaction, otherwise the JMS transaction will rollback together
with the JPA one :(

thanks a lot for the tips, now it is time to refactor and blog <- to
not forget anymore :)

2009/9/23 Felipe Gaścho <fgaucho_at_gmail.com>:
> Thank you very much.. I will try this..
>
> the exception is
>
> MDB's onMessage() {
>   call EntityManager.persist and this throws an EntityAlreadyExists
> Exception...
> }
>
> the root of the redelivery is a JPA exception .. I am not sure if
> there is a relationship between this and the JMS behavior
>
> On Wed, Sep 23, 2009 at 12:24 AM, Nigel Deakin <Nigel.Deakin_at_sun.com> wrote:
>> Felipe Gaścho wrote:
>>>
>>> there is no mechanism in Glassfish where I can say: "stop after
>>> n-trials", doesn't matter what.. to preserve the server ?
>>
>> If an exception is being thrown in the MDB's onMessage() method, and you're
>> using the JMSRA resource adapter, the redelivery of messages should be
>> controlled by the ActivationSpec properties
>> endpointExceptionRedeliveryAttempts and sendUndeliverableMsgsToDMQ.
>>
>> endpointExceptionRedeliveryAttempts (default=6) specifies the "Number of
>> times to redeliver a message when MDB throws an exception during message
>> delivery"
>>
>> sendUndeliverableMsgsToDMQ (default=true) specifies that MQ should "Place
>> message in dead message queue when MDB throws a runtime exception and number
>> of redelivery attempts exceeds the value of
>> endpointExceptionRedeliveryAttempts"
>>
>> http://docs.sun.com/app/docs/doc/820-6740/aeoon?a=view
>>
>> Does this match what you are seeing?
>>
>> Nigel
>>
>>
>>>
>>> 2009/9/22 Felipe Gaścho <fgaucho_at_gmail.com>:
>>>>
>>>> may I force the transaction on the JMS Queue ??
>>>>
>>>> 2009/9/22 Felipe Gaścho <fgaucho_at_gmail.com>:
>>>>>
>>>>> Yes, I know.. and I will verify.. problem is: anytime any problem
>>>>> happens in the code, it destroy the Glassfish instance and makes the
>>>>> machine itself useless due to the amount of log files generated by the
>>>>> deadlock..
>>>>>
>>>>> Is there a way to prevent that ?
>>>>>
>>>>>
>>>>>
>>>>> I tought a try-catch(Exception) would stop the exception fall :(
>>>>>
>>>>
>>>>
>>>> --
>>>> Looking for a client application for this service:
>>>> http://fgaucho.dyndns.org:8080/footprint-service/wadl
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
>
>
> --
> Looking for a client application for this service:
> http://fgaucho.dyndns.org:8080/footprint-service/wadl
>



-- 
Looking for a client application for this service:
http://fgaucho.dyndns.org:8080/footprint-service/wadl