activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Serrano (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-4157) KahaDBTransactionStore.removeAyncMessage may cancel addMessage when in transaction leading to unpersisted messages
Date Fri, 02 Nov 2012 19:07:15 GMT
Martin Serrano created AMQ-4157:
-----------------------------------

             Summary: KahaDBTransactionStore.removeAyncMessage may cancel addMessage when
in transaction leading to unpersisted messages
                 Key: AMQ-4157
                 URL: https://issues.apache.org/jira/browse/AMQ-4157
             Project: ActiveMQ
          Issue Type: Bug
          Components: Message Store
    Affects Versions: 5.7.0
         Environment: linux 64-bit, kahadb, persisted messages, cached dest, transacted
            Reporter: Martin Serrano
            Priority: Blocker


This was very difficult to track down.  It rarely occurs because a certain set of events must
be occurring to trigger the bug.   I have marked it a Blocker because when it does occur,
it is silent and leads to a message not being persisted in the MessageStore.

*Description*
The crux of the bug is that when a rollback on a session occurs, the resulting MessageAck
can overlap with the async store of the message in the KahaDB.   When this occurs, the message
is never persisted.  Additionally, the resultant {{CancellationException}} is ignored in o.a.a.broker.region.Queue:796.
  The steps:

# a StoreQueueTask is created to add a message X.  this is put on the async task queue
# meanwhile this message is dispatched via a prefetch subscription to a transacted consumer.
# the transacted consumer calls session.rollback
# this leads to acknowledgement of the dispatched messages 
# as a result destination.removeAsyncMessage is called
# if the original add has not yet executed then it will be cancelled leading to the message
never being persisted!  (occurs at KahaDBStore:401)

I have not been able to reproduce this in a small activemq-only test.  But I can reproduce
it in my environment.  

*Proposed Solutions*
I think the issue lies either with the 


*Workaround*
* turn off caching for the destination (see [dest policies|http://activemq.apache.org/per-destination-policies.html]).
 this will cause messages to be added to the synchronously so they will not be subject to
the async cancellation

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

Mime
View raw message