activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (AMQ-4952) When duplicate message occur from network producer, messages blocked by cursor audit are blocked till restart
Date Wed, 08 Jan 2014 12:53:56 GMT

     [ https://issues.apache.org/jira/browse/AMQ-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary Tully resolved AMQ-4952.
-----------------------------

    Resolution: Fixed

when the cursor detects a duplicate the message is removed and referred for DLQ processing
with a reasonCause of "duplicate from store"
Thus it does not remain "stuck" till a restart. The typical use case where this can occur
is with a duplicate forward from a network connector that fails  before getting a send reply
happens after the original message has been dispatched. So the store does not trap the duplicate
but the cursor does.

http://git-wip-us.apache.org/repos/asf/activemq/commit/f92d45be

> 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.5#6160)

Mime
View raw message