[
https://issues.apache.org/jira/browse/AMQ-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854620#comment-13854620
]
Gary Tully commented on AMQ-4952:
---------------------------------
linking to https://issues.apache.org/jira/browse/AMQ-4465 for more context
need to deal with duplicates to prevent eventuall delivery from
https://issues.apache.org/jira/browse/AMQ-4924
> When duplicate message occur from network producer, messages blocked by
> cursor audit are blocked till restart
> -------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-4952
> URL: https://issues.apache.org/jira/browse/AMQ-4952
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 5.9.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: duplicate, network, stuck
> Fix For: 5.10.0
>
>
> If auditNetworkProducers is off (as it is by default) a reforward (because of
> a missing send reply) will be a duplicate.
> If the initial messages is still in the store the duplicate will be trapped
> by the message cursor but the message remains in the store. So on a restart
> the cursor is fresh (unless in the case of jdbc when there are still messages
> in the store) and the message gets redispatched. In the jdbc case - if the
> store/destination is empty there will be a resend b/c there is no sequence
> state to replay.
> Duplicates detected by the cursor need to deal with the duplicate message -
> moving to the DLQ makes the most sense - the cause can indicate the reason
> to allow separation from poison due to redelivery failure.
> Client duplicate detection currently uses a poison ack, so this makes the
> behaviour consistent.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
