activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Naseef (JIRA)" <>
Subject [jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
Date Thu, 29 Jan 2015 03:31:34 GMT


Arthur Naseef commented on AMQ-5542:

DLQs are a common cause of this problem.  My recommendation when using DLQs is *always* have
a plan for handling them and consume them in a timely manner.

Again, if the messages need to be stored for a period of time (like 2 days), the best approach
is to get them out of ActiveMQ and put them in some type of message store.  Another consideration
of this use-case: keeping the messages for this period means some manual action is expected.
 ActiveMQ is not designed to give "random access" to messages, which would typically be needed
for manual intervention, but instead to produce and consume as a queue.  This use-case would
be better served with a database in which individual messages could be referenced.

Regardless, this is how ActiveMQ currently functions.  Until something better is implemented,
these data files must not be deleted until they are no longer used.

> KahaDB data files containing acknowledgements are deleted during cleanup
> ------------------------------------------------------------------------
>                 Key: AMQ-5542
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Message Store
>    Affects Versions: 5.10.0, 5.10.1
>            Reporter: Sergiy Barlabanov
>         Attachments: AMQ-5542.patch, AdjustedAMQ2832Test.patch
> AMQ-2832 was not fixed cleanly.
> The commit dd68c61e65f24b7dc498b36e34960a4bc46ded4b by Gary from 8.10.2010 introduced
a problem by deleting too many files.
> Scenarios we are facing currently in production:
> Data file #1 contains unconsumed messages sitting in a DLQ. So this file is not a cleanup
> The next file #2 contains acks of some messages from file #1. This file is not a cleanup
candidate (because of ackMessageFileMap logic).
> The next file #3 contains acks of some messages from file #2. And this file is deleted
during the cleanup procedure. So on Broker restart all messages from #2, whose acks were from
the deleted file #3, are replayed!
> The reason is gcCandidates variable, which is a copy of gcCandidateSet (see MessageDatabase#checkpointUpdate
at the end of the method - org/apache/activemq/store/kahadb/ on 5.10.0
tag). So when a candidate is deleted from gcCandidateSet (org/apache/activemq/store/kahadb/
on 5.10.0 tag), gcCandidates still contains that candidate and the comparison on org/apache/activemq/store/kahadb/
works wrong!
> I will try to adjust AMQ2832Test.

This message was sent by Atlassian JIRA

View raw message