Return-Path: X-Original-To: apmail-activemq-dev-archive@www.apache.org Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BC9D117F5F for ; Tue, 6 Jan 2015 03:43:33 +0000 (UTC) Received: (qmail 99924 invoked by uid 500); 6 Jan 2015 03:43:34 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 99852 invoked by uid 500); 6 Jan 2015 03:43:34 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 99838 invoked by uid 99); 6 Jan 2015 03:43:34 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jan 2015 03:43:34 +0000 Date: Tue, 6 Jan 2015 03:43:34 +0000 (UTC) From: "Timothy Bish (JIRA)" To: dev@activemq.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Closed] (AMQ-5507) "Duplicate dispatch on connection" with more than 2^31 messages MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/AMQ-5507?page=3Dcom.atlassian.= jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-5507. ----------------------------- Resolution: Duplicate Please direct questions to the user mailing list. > "Duplicate dispatch on connection" with more than 2^31 messages > --------------------------------------------------------------- > > Key: AMQ-5507 > URL: https://issues.apache.org/jira/browse/AMQ-5507 > Project: ActiveMQ > Issue Type: Bug > Components: Broker > Affects Versions: 5.8.0, 5.10.0 > Reporter: Sam hendley > Fix For: 5.11.0 > > > A few times over the last few years the busiest queue in our system would= suddenly start spewing these "Duplicate dispatch on connection" warning me= ssages into the log and 0 messages would be processed. Googling around the = only references I could find mentioned "optimize acknowledge" may be at fau= lt. We stopped using that feature and I though perhaps this issue was gone = but it popped up again today. > The log messages look like this: > {noformat} > 2015-01-05 20:25:21,310 [ActiveMQ Session Task-2341 ] WARN apach= e.activemq.ActiveMQMessageConsumer - Duplicate dispatch on connection: ID:p= erf4-flexapp-43114-1419911988672-9:1 to consumer: ID:perf4-flexapp-43114-14= 19911988672-9:1:1:1, ignoring (auto acking) duplicate: MessageDispatch {com= mandId =3D 0, responseRequired =3D false, consumerId =3D ID:perf4-flexapp-4= 3114-1419911988672-9:1:1:1, destination =3D queue://*********, message =3D = ActiveMQBytesMessage {commandId =3D -497935582, responseRequired =3D false,= messageId =3D ID:perf4-nc-49600-1419436870976-1:8:1:1:3797031711, original= Destination =3D null, originalTransactionId =3D null, producerId =3D ID:per= f4-nc-49600-1419436870976-1:8:1:1, destination =3D queue://*********, trans= actionId =3D null, expiration =3D 0, timestamp =3D 1420507504378, arrival = =3D 0, brokerInTime =3D 1420507504527, brokerOutTime =3D 1420507521253, cor= relationId =3D null, replyTo =3D null, persistent =3D true, type =3D null, = priority =3D 4, groupID =3D null, groupSequence =3D 0, targetConsumerId =3D= null, compressed =3D false, userID =3D null, content =3D org.apache.active= mq.util.ByteSequence@477f9261, marshalledProperties =3D null, dataStructure= =3D null, redeliveryCounter =3D 0, size =3D 0, properties =3D null, readOn= lyProperties =3D true, readOnlyBody =3D true, droppable =3D false} ActiveMQ= BytesMessage{ bytesOut =3D null, dataOut =3D null, dataIn =3D null }, redel= iveryCounter =3D 0} > {noformat} > I randomly noticed that the "commandId" was negative. I looked at the mes= sageId and sure enough it is very large, in the 2^31 range. I checked all m= y field reports for this bug and in all cases the id was just over 2^31. I = dug into the activemq code and found the issue was the BitArrayBin class do= esn't handle values of that size correctly. I was about to post that as a c= ritical bug but found it had already been reported and fixed for 5.11.0 in = another context. AMQ-5016 > In case other people have a system stable enough to generate 2^31 message= s from a single producer they should know they can add the setting "?checkF= orDuplicates=3Dfalse" at the queue or connection level. Are there any other= mitigation strategies I may not know? -- This message was sent by Atlassian JIRA (v6.3.4#6332)