Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 9 Jan 2014 12:22:51 +0000 (UTC)
From: "Gary Tully (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12685909.1387577741224.68271.1389270171523@arcas>
In-Reply-To: <JIRA.12685909.1387577741224@arcas>
References: <JIRA.12685909.1387577741224@arcas>
Subject: [jira] [Commented] (AMQ-4952) When duplicate message occur from
 network producer, messages blocked by cursor audit are blocked till restart
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AMQ-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13866595#comment-13866595 ] 

Gary Tully commented on AMQ-4952:
---------------------------------

dealt with the audit false case and duplicate in pagedInMessages - now redirecting to DLQ and removing from the store in that case also
http://git-wip-us.apache.org/repos/asf/activemq/commit/cc47ab6d

JDBC store does not have a separate index to trap the duplicate that is still inflight. Also, cursor audit window may be too small for some use cases.
If there is a valid usecase where duplicates are acceptable we can revisit but all tests currently pass with the change that 'outlaws' and deals with duplicates.

> 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)