[
https://issues.apache.org/jira/browse/AMQ-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reopened AMQ-2832:
-------------------------------
Assignee: Timothy Bish (was: Gary Tully)
Unfortunately this wasn't really fully fixed. The tracking of acks isn't
persistent so a broker restart between the acks and the recovery can lose track
of the ack and allow its data file to be deleted resulting in a recovered
message that was previously consumed to be redispatched.
> Possible replay of old messages post index recovery from journal - data files
> containing acks reclaimed/cleaned up in error
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-2832
> URL: https://issues.apache.org/jira/browse/AMQ-2832
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.3.2
> Reporter: Gary Tully
> Assignee: Timothy Bish
> Fix For: 5.4.0
>
>
> With long lived messages and outstanding acks, ack distribution can be sparse
> across data files. If a data file is in use (still has unreferenced messages,
> the data files containing acks for all those messages also need to be
> maintained to ensure a replay of the journal replays the corresponding acks.
> Currently it is possible that data files with no unreferenced messages but
> with acks pertinent to an in use data file can get deleted. The result is
> duplicate or relay of old messages after journal recovery (following a
> crash/restart)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
