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.
