[
https://issues.apache.org/jira/browse/AMQ-6133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221784#comment-15221784
]
Christopher L. Shannon commented on AMQ-6133:
---------------------------------------------
[~gtully], After some testing, I agree with your assessment to do nothing.
Indeed it doesn't really make any sense to try and make the two features
coexist. One issue of trying to update a message async is then you can't
guarantee that it was persisted before dispatch so you negate any benefits. And
you already alluded to this when you mentioned the point is to persist before
dispatch. In fact, if anything, I'm seeing slower message rates with added
synchronization from trying to do the update.
In the doMessageSend() method inside Queue where asyncAddQueueMessage() is
called, do you think it makes sense to check there if the destination has
persistJmsRedelivered enabled and if it does call addMessage() instead? Or
just leave it alone and document it?
> 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)
