[
https://issues.apache.org/jira/browse/AMQ-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295399#comment-14295399
]
Arthur Naseef commented on AMQ-5542:
------------------------------------
To Tim's point -- if there is *any* content in the data file that means it is
needed, then the file must not be removed. That problem exists even for
messages - one, small message can hold an entire data file.
Therefore, if there is an acknowledgement in the data file that still needs to
be processed, the data file must not be removed.
As Gary mentioned, multi-kahadb can be used to better prevent the scenario of
large holes in data files.
Keep in mind - it's in the JMS specification that consumers are expected to be
"timely" (I forget the exact wording). ActiveMQ (and other JMS solutions) are
not "message stores" - using them as such leads to many issues. If messages
need to be stored for a length of time, I generally recommend adding a store to
the architecture and moving those messages out of ActiveMQ and into the store
as-needed.
With that said, a solution to the compaction problem would be quite welcome.
> KahaDB data files containing acknowledgements are deleted during cleanup
> ------------------------------------------------------------------------
>
> Key: AMQ-5542
> URL: https://issues.apache.org/jira/browse/AMQ-5542
> 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 candidate.
> 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/MessageDatabase.java:1659 on 5.10.0 tag). So
> when a candidate is deleted from gcCandidateSet
> (org/apache/activemq/store/kahadb/MessageDatabase.java:1668 on 5.10.0 tag),
> gcCandidates still contains that candidate and the comparison on
> org/apache/activemq/store/kahadb/MessageDatabase.java:1666 works wrong!
> I will try to adjust AMQ2832Test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
