Skip to main content

JMS exception causing resending message :(

12 replies [Last post]
Anonymous

again I am facing this problem .. and again lost :)

in my method:

private PujUserEntity createNewCustomer(Message registration) {
try {
.....
} catch (Exception error) {
logger.log(Level.WARNING, "unable to create user [login= " + login
+ ", email=" + email, error);
}
return user;
}

and when the code causes a JPA exception, the message is sent again to
the Queue...

How do I digest the message in a way it never more is delivered ?

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

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

Reply viewing options

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

How does a deadlock come into the picture?

thanks,
-marina

Felipe Gaúcho wrote:
> 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 :(
>
> ---------------------------------------------------------------------
> 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

Felipe Gaúcho

and the method that calls the previous one:

@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Queue") }, mappedName =
JmsConstants.PUJ_REGISTRATION_QUEUE)
public class RegistrationMessageBean implements MessageListener {

@Override
public void onMessage(Message registration) {
try {
.........
PujUserEntity user = createNewCustomer(registration);
.........
} catch (Throwable ex) {
logger.log(...);
}
}
}

and the message continue to be redelivered :(

2009/9/22 Felipe Gaúcho :
> again I am facing this problem .. and again lost :)
>
> in my method:
>
>        private PujUserEntity createNewCustomer(Message registration) {
>                try {
>                           .....
>                } catch (Exception error) {
>                        logger.log(Level.WARNING, "unable to create user [login= " + login
>                                        + ", email=" + email, error);
>                }
>                return user;
>        }
>
>
> and when the code causes a JPA exception, the message is sent again to
> the Queue...
>
> How do I digest the message in a way it never more is delivered ?
>
> --
> 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

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

Marina Vatkina

Make that other one RequiresNew transaction type.

Regards,
-marina

Felipe Gaúcho wrote:
> and the method that calls the previous one:
>
> @MessageDriven(activationConfig = {
> @ActivationConfigProperty(propertyName = "destinationType",
> propertyValue = "javax.jms.Queue") }, mappedName =
> JmsConstants.PUJ_REGISTRATION_QUEUE)
> public class RegistrationMessageBean implements MessageListener {
>
> @Override
> public void onMessage(Message registration) {
> try {
> .........
> PujUserEntity user = createNewCustomer(registration);
> .........
> } catch (Throwable ex) {
> logger.log(...);
> }
> }
> }
>
> and the message continue to be redelivered :(
>
> 2009/9/22 Felipe Gaúcho :
>
>>again I am facing this problem .. and again lost :)
>>
>>in my method:
>>
>> private PujUserEntity createNewCustomer(Message registration) {
>> try {
>> .....
>> } catch (Exception error) {
>> logger.log(Level.WARNING, "unable to create user [login= " + login
>> + ", email=" + email, error);
>> }
>> return user;
>> }
>>
>>
>>and when the code causes a JPA exception, the message is sent again to
>>the Queue...
>>
>>How do I digest the message in a way it never more is delivered ?
>>
>>--
>>Looking for a client application for this service:
>>http://fgaucho.dyndns.org:8080/footprint-service/wadl
>>
>
>
>
>

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

Felipe Gaúcho

??

if I just merge the two methods it will solve the problem ?

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

Marina Vatkina

No, because the transaction will fail, and the message will be redelivered. I
didn't realize they are methods of the same bean - make createNewCustomer() a
method on another bean that runs in its own transaction, then transaction will
fail, but onMessage won't.

Another option would be to verify that the customer can be created before doing
em.persist(0 and not fail the transaction in the 1st place.

HTH,
-marina

Felipe Gaúcho wrote:
> ??
>
>
> if I just merge the two methods it will solve the problem ?
>
> ---------------------------------------------------------------------
> 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

Felipe Gaúcho

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

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

Felipe Gaúcho

may I force the transaction on the JMS Queue ??

2009/9/22 Felipe Gaúcho :
> 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@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Felipe Gaúcho

there is no mechanism in Glassfish where I can say: "stop after
n-trials", doesn't matter what.. to preserve the server ?

2009/9/22 Felipe Gaúcho :
> may I force the transaction on the JMS Queue ??
>
> 2009/9/22 Felipe Gaúcho :
>> 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
>

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

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

Nigel Deakin

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 :
>> may I force the transaction on the JMS Queue ??
>>
>> 2009/9/22 Felipe Gaúcho :
>>> 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@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Felipe Gaúcho

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 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 :
>>>
>>> may I force the transaction on the JMS Queue ??
>>>
>>> 2009/9/22 Felipe Gaúcho :
>>>>
>>>> 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@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

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

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

Felipe Gaúcho

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 :
> 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 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 :
>>>>
>>>> may I force the transaction on the JMS Queue ??
>>>>
>>>> 2009/9/22 Felipe Gaúcho :
>>>>>
>>>>> 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@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@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

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

Marina Vatkina

I also suggested an option to do a query first and check if such instance
already exist, then decide whether to call em.persist() or not :). Tx rollback
is never optimized, so if you have it often, the query will be faster.

But I'm glad you have a solution.

Regards,
-marina

Felipe Gaúcho wrote:
> 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 :
>
>>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 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 :
>>>>
>>>>>may I force the transaction on the JMS Queue ??
>>>>>
>>>>>2009/9/22 Felipe Gaúcho :
>>>>>
>>>>>>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@glassfish.dev.java.net
>>>For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>>
>>
>>
>>
>>--
>>Looking for a client application for this service:
>>http://fgaucho.dyndns.org:8080/footprint-service/wadl
>>
>
>
>
>

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