activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Impact of checkForDuplicates = false
Date Tue, 13 Jan 2015 15:04:14 GMT
the case where it is necessary is when a client connection drops
between sending an ack and the broker receiving the ack. So the broker
will redispatch the message when the consumer reconnects (when
failover kicks in).
If there is no failover the consumer and connection will die.
If the ack is in a transaction, the duplicate can be tracked if the
consumer id matches and the transaction can be recovered/recreated by
failover. If the id does not match, then the transaction is rolled
back in this case.

The question for your app is, can the client accept a duplicate
receipt if an ack is lost? If so, then disable checkForDuplicates.
Also note, that the audit bit array is per producer (the message ids
are assigned by producers) so you may be able to reduce
the number or tracked producers to cause the bitarraybin to get
dropped. There are some options to control that see:

On 13 January 2015 at 14:42, Hendley, Sam <> wrote:
> Due to our large and stable systems will
hit the 2^31 + 1 message limit after a few days. I gather that the "checkForDuplicates" flag
will prevent the "Duplicate dispatch on connection" issue. I can set that flag on just our
highest volume queues but that just delays the problem a bit (when a lower volume queue hits
the same limit), I would like to set that flag system wide but would like to know more about
what I am disabling.
> I haven't been able to find a lot of documentation on this flag. What are the risks of
disabling duplicate checking system wide? Are there any cases where this flag must stay enabled?
Our usage of activemq is pretty basic, all AUTO_ACK and no transactions so I am guessing we
should be safe but I can't be sure. We do use failover:tcp: connector but only for the reconnecting,
we only have a single broker.
> Sam

View raw message