[
https://issues.apache.org/jira/browse/AMQ-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845437#comment-13845437
]
Ron Koerner commented on AMQ-4924:
----------------------------------
So if I have no duplex connection I need to activate auditNetworkProducer on
the receiving TransportConnector (in my case "LOCAL") and if I have a duplex
connection I need to activate checkDuplicateMessagesOnDuplex on the sending
NetworkConnector (in my case "REMOTE").
But when messages are sent from REMOTE to LOCAL the DemandForwardingBridge on
the LOCAL side will actually check for the duplicate, even if it is configured
only on the REMOTE side.
As soon as 5.10 is released I will change my setup accordingly. For now I can
use supportFailOver as a workaround.
Thank you very much!
Other people with this problem may appreciate a hint to use
auditNetworkProducers or checkDuplicateMessagesOnDuplex whenever they encounter
the situation that there is a duplicate detected by the cursor.
> Duplicate messages are left in the persistence store
> ----------------------------------------------------
>
> Key: AMQ-4924
> URL: https://issues.apache.org/jira/browse/AMQ-4924
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.8.0, 5.9.0
> Reporter: Ron Koerner
> Assignee: Rob Davies
> Fix For: 5.10.0
>
> Attachments: AMQ4924.java
>
>
> We have a local and remote broker connected with a duplex bridge, which is
> initiated by the remote broker.
> Producers are attached to the remote broker, one consumer to the local broker.
> The following scenario causes messages to be left in the local store, which
> are replayed when the local broker is restarted:
> # messages are forwarded from the remote broker to the local broker
> # messages are dispatched to the local consumer
> # the connection between the local and remote broker fails
> # the local broker tries to acknowledge the message reception to the remote
> broker, which fails
> # the remote broker reconnects
> # the messages are resent
> # the local broker correctly identifies them as duplicates, but puts them
> into the store nevertheless where they remain until the local broker is
> restarted
> # other messages are produced and consumed without a problem
> # the local broker is restarted
> # the duplicates are now delivered to the local consumer again and of course
> out of order
> This behaviour can be identified by a queue size which does not seem to
> shrink below a certain number, even if a consumer is connected and consuming
> other messages.
> When the log level is set to TRACE these messages indicate the problem:
> {code}
> 2013-12-06 20:35:17,405 TRACE .a.a.b.r.c.AbstractStoreCursor -
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch@c0bc4f:testqueue,batchResetNeeded=false,storeHasMessages=true,size=0,cacheEnabled=true,maxBatchSize:1
> - cursor got duplicate: ID:smcexp5-58011-1386358514283-7:1:1:1:1, 4
> [ActiveMQ VMTransport: vm://LOCAL#19-1]
> 2013-12-06 20:35:17,412 TRACE .a.a.b.r.c.AbstractStoreCursor -
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch@c0bc4f:testqueue,batchResetNeeded=false,storeHasMessages=false,size=1,cacheEnabled=false,maxBatchSize:1
> - fillBatch [ActiveMQ BrokerService[LOCAL] Task-2]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
