activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Pure Master/Slave Bug? Expired messages not replicated to Slave - update
Date Tue, 06 Jul 2010 08:51:32 GMT
This looks like a bug, can u open a jira issue to track this. I think
that audit on TransactionBroker has caused a problem before, not sure
what duplicates it is intended to suppress.

Out of interest, what is your use case for pure master slave?
Due to the limitations of restarting master/slave pairs (both need to
be restarted in order) and the fact that only the master can fail, it
tends not be get that much use in production and as a result not that
much attention w.r.t bug fixes. Having said that, what is there should
work as expected with its limitations.

You may want to consider using a shared file system master/slave setup.

On 5 July 2010 14:59, <> wrote:
> Update: Same problem with ActiveMQ 5.3.0, current 5.3.3- and current 5.4-SNAPSHOT.
> Any ideas?
>  Andreas
> -----Ursprüngliche Nachricht-----
> Von: Weber, Andreas, M-ED
> Gesendet: Montag, 5. Juli 2010 09:47
> An: ''
> Betreff: Pure Master/Slave Bug? Expired messages not replicated to Slave
> Hi,
> I use a Pure Master/Slave configuration with ActiveMQ 5.3.2.
> Master/Slave both use the same DLQ configuration with: processExpired="true" processNonPersistent="true"
> The normal Master/Slave processing seems to work correctly, actions on Master are always
replicated to the Slave.
> But there's a problem: Expired messages do go to the Master's DLQ, but this is not adapted
in the Slave.
> I debugged in the (Slave's) Code and found the appropriate send-to-DLQ-Command/Message
arriving at the MasterConnector.
> But in further processing this message is filtered out as a duplicate(?) (TransactionBroker.send()
resp. ActiveMQMessageAudit.isDuplicate()). It seems that this ProducerSequenceBit, which is
checked there, was already set... but here I'm a little bit lost in the code.
> So, any ideas why this happens?
> Some further note/question: A Slave also seems to have its own Timer to look for expired
messages in the queues, even if the Master is still alive. Is that really intended?
> So in the szenario above, the Slave also generates a message to the DLQ for its expired
item. But this is filtered out as a duplicate, too. That may be ok here if "normal replication"
would work, but I'm generally not sure if a Slave should really run it's own timeout checking
of expired messages at all, as long as he's not become a Master.
> Best regards,
>  Andreas


Open Source Integration

View raw message