activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Bain (JIRA)" <>
Subject [jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
Date Wed, 28 Jan 2015 17:34:36 GMT


Tim Bain commented on AMQ-5542:

Consumers can be timely but unsuccessful, leading to messages going to the DLQ, where they
can cause exactly this kind of behavior.  So as ActiveMQ is currently implemented the expectation
Art referenced (that consumers be timely) needs to be applied to the DLQ as well, which isn't
how I'd expect to need to interact with a DLQ.  I would assume that I could come in the next
morning, see that there were messages in the DLQ that failed for some reason, and decide what
to do about them.  But even if we simply fix this bug by not deleting the KahaDB files that
are still needed (potentially all of them), then the consequence of that is going to be potentially
large KahaDB disk usage for just a few messages, which I think most developers/admins won't
be expecting.

The way I just described interacting with the DLQ does in fact use it as a message store,
and I think that's a valid use case.

I think that fixing this specific bug is better than not (high disk usage is better than invalid
message redelivery, IMO), but I think another solution (which could be mKahaDB, or something
else such as having a separate KahaDB for the DLQ) is still needed (in a separate JIRA enhancement).
 I submitted AMQ-5547 to capture that need.

> 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