[
https://issues.apache.org/jira/browse/AMQ-6133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon reopened AMQ-6133:
-----------------------------------------
I'm seeing a race condition issue here where some duplicate messages end up in
the store. The issue occurs when persistJmsRedelivered is turned on for a Queue
and concurrentStoreAndDispatchQueues is used.
What I'm seeing is that when rapidly producing/consuming, after a consumer gets
all of the messages, sometimes the message reappears. The cause seems to be
that sometimes the message has been acked by the consumer and removed after it
has been added to the store but before the update command runs (to set the
redelivered flag). So what happens with this fix is that at the end it will
try to update a non-existent message so it will end up re-adding it.
In a test on my machine with 1 producer/consumer rapidly producing and
consuming 50k messages, at the end of the test I consistently see 10-20
messages left over in the store even though the consumer has already received
them all.
I'm investigating more now to see if there is a good way to fix this without
having to completely back out this patch.
> Message updates can cause message loss on recovery
> --------------------------------------------------
>
> Key: AMQ-6133
> URL: https://issues.apache.org/jira/browse/AMQ-6133
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, KahaDB
> Affects Versions: 5.13.0
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
> Attachments: AMQ6133PersistJMSRedeliveryTest.java, AMQ6133Test.java
>
>
> After doing some testing with AMQ-6131, I noticed a similar issue where
> messages can be lost if a message update is called.
> Normally when KahaDB gets a KahaUpdateMessageCommand it will update the index
> with the new location. This works except that if the index is deleted or
> corrupted and needs to be rebuilt, the replay process may not be able to
> recover the message.
> This happens because after the message is updated, KahaDB is free to garbage
> collect the file with the original add command. So, whatt happens is that
> during replay when the update command is seen KahaDB rejects it because it
> can't find the original message if that file has been GC'd. This happens in
> the updateIndex method of MessageDatabase on line 1395 where it prints out a
> warning saying "Non existent message update attempt rejected".
> I am attaching a unit test that demonstrates the issue where the count after
> restart is missing messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
