Re: Reconciliation after ActiveMQ server crash.

[thabach <ba...@evolootion.ch>]

rajdavies wrote:
> 
> This is handled by the ActiveMQ failover transport (the default in 5.1  
> onwards).
> It replays messages on your behalf that haven't been acknowledged -  
> 
You refer to the case when the connection was only temporarily lost, and the
client runtime would autonomously do a resend on successful (re-)connect to
the same or a fail-over broker, right ? 

But what if there is only one broker and the runtime decides to inform
application layers by throwing an exception - then the resend has to be done
by application layers. Is it possible somehow from an application level to
utilize the "internal" duplicate detection in reconciliation when targeting
the original broker a second time after it recovered ?


rajdavies wrote:
> 
> ... there is duplicate detection built in to the broker and the clients  
> too ...
> 
Does this imply that there is a configurable JMS message ID backlog
maintained by ActiveMQ on the broker side as well as in client runtime
instances ? Is this all similar in concept to SwiftMQ duplicate detection
(http://www.swiftmq.com/products/harouter/advanced/duplicate/index.html) ? 

I would appreciate if you could elucidate the ActiveMQ support in duplicate
detection even more, thank you very much. Christian.
-- 
View this message in context: http://www.nabble.com/Reconciliation-after-ActiveMQ-server-crash.-tp20734165p20801684.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.