Re-reading through my email backlog, I noticed this.
ActiveMQ already provides that type of persistence and guarantee of
delivery. Any additional implementation seems redundant - unless there are
some mitigating factors.
Art
On Fri, Jun 1, 2018 at 3:24 AM, gerardl wrote:
> Thanks Art. Some
Thanks Art. Some good feedback. The guaranteed delivery is important, so I'm
going to need to implement an extension to support local storage of unsent
messages so they can be redelivered when a resume has been detected.
--
Sent from:
Sounds like that is getting into details that JMS intends to handle.
At some level, every application is going to need to chose between the
possibility of duplicating a message, or losing a message. There is no way
to 100% avoid both cases at the same time. With that said, ActiveMQ has
Hi,
I have implemented the failover transport and TransportListener interface.
So, the transport listener receives the interrupt/resume and sets an
internal flag in the connector itself, lets call it connectionActive. When a
message gets dequeued for sending by the connector, I take an optimistic
My recommendation is to use the Failover transport and the
TransportListener interface.
To use the failover transport, just use the following syntax for the broker
url:
failover://(*_original_broker_url_*)
For example, with a broker at localhost:61616,
failover://(tcp://localhost:61616),
