[
https://issues.apache.org/jira/browse/AMQ-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Manuel Lopez updated AMQ-4687:
-----------------------------------
Description:
ActiveMQ does a trx commit when there is a transaction timeout
(EJBTransactionRolledbackException). In this way we are losing messages when
there is any timeout.
We have seen that the activemq connections are enlist in XA.
The attribute transactionContext from ActiveMQSession class has the global
transaction reference (xid) before calling the MDB
(messageListener.onMessage(message)).
When the timeout is reached and the RuntimeException is throwned, the
transactionContext losed the xid reference.
Later, when ActiveMQSession call the method
transactionContext.isInXATransaction() the result is false because there is no
xid reference.
This situation only happened when the MDB calls other EJB (Stateless) with CMT
- TransactionAttributeType.REQUIRES_NEW, and the exception is throwed inside
the Stateless.
I've tried to reproduce this without calling the stateless ejb but it works
well.
The ActiveMQSession class should retain the original transactionContext.
I found these is the same problem jira
https://issues.apache.org/jira/browse/AMQ-4634 but is possible move this fix
into version ActiveMQ 5.6 ?
Regards
was:
ActiveMQ does a trx commit when there is a transaction timeout
(EJBTransactionRolledbackException). In this way we are losing messages when
there is any timeout.
We have seen that the activemq connections are enlist in XA.
The attribute transactionContext from ActiveMQSession class has the global
transaction reference (xid) before calling the MDB
(messageListener.onMessage(message)).
When the timeout is reached and the RuntimeException is throwned, the
transactionContext losed the xid reference.
Later, when ActiveMQSession call the method
transactionContext.isInXATransaction() the result is false because there is no
xid reference.
I found this jira https://issues.apache.org/jira/browse/AMQ-4634 but is
possible move this fix into version ActiveMQ 5.6 ?
This situation only happened when the MDB calls other EJB (Stateless) with CMT
- TransactionAttributeType.REQUIRES_NEW, and the exception is throwed inside
the Stateless.
I've tried to reproduce this without calling the stateless ejb but it works
well.
The ActiveMQSession class should retain the original transactionContext.
Priority: Critical (was: Major)
> Rar losing messages when there is a XA trx timeout (jboss)
> -----------------------------------------------------------
>
> Key: AMQ-4687
> URL: https://issues.apache.org/jira/browse/AMQ-4687
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.6.0
> Environment: Jboss 6.0.1, JDK 1.6, ActiveMQ 5.6
> Reporter: Juan Manuel Lopez
> Priority: Critical
> Fix For: 5.x
>
>
> ActiveMQ does a trx commit when there is a transaction timeout
> (EJBTransactionRolledbackException). In this way we are losing messages when
> there is any timeout.
> We have seen that the activemq connections are enlist in XA.
> The attribute transactionContext from ActiveMQSession class has the global
> transaction reference (xid) before calling the MDB
> (messageListener.onMessage(message)).
> When the timeout is reached and the RuntimeException is throwned, the
> transactionContext losed the xid reference.
> Later, when ActiveMQSession call the method
> transactionContext.isInXATransaction() the result is false because there is
> no xid reference.
> This situation only happened when the MDB calls other EJB (Stateless) with
> CMT - TransactionAttributeType.REQUIRES_NEW, and the exception is throwed
> inside the Stateless.
> I've tried to reproduce this without calling the stateless ejb but it works
> well.
> The ActiveMQSession class should retain the original transactionContext.
> I found these is the same problem jira
> https://issues.apache.org/jira/browse/AMQ-4634 but is possible move this fix
> into version ActiveMQ 5.6 ?
> Regards
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
