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
duplicate detection so it does make a best-effort to avoid duplication. If
needed, I can clarify this dilemma further.
In the application, if you chose to eliminate the possibility of lost
messages, the following logic flow should work well:
ON message READY
SYNC SEND message TO broker
IF send WAS successful
THEN
MARK message COMPLETE
END IF
Notice that a crash, or other failure, after the send to the broker
actually reached the wire, and before the "MARK message COMPLETE" step will
lead to a duplicate message. Note that some supporting details are lacking.
On the other hand, if duplicates cannot be tolerated:
ON message READY
MARK message COMPLETE
SEND message TO broker
Any logic in the application that attempts to detect whether it is able to
successfully send to the broker is redundant with work already done inside
the client library. And even if the application detects that it "was"
connected, that's no guarantee that the next send will actually succeed.
I'm ignoring many details here because a lot depends on the full solution,
and there are many possible ways all of this plays out. If there is a need
to provide a guarantee of delivery to an upstream requestor, then having a
form of local storage / persistent-queue for the messages is prudent.
Hope this helps.
Art
On Thu, May 31, 2018 at 3:41 AM, gerardl <ger.law...@gmail.com> wrote:
> 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
> approach and attempt to send. However we might be momentarily disconnected
> and as the message was dequeued for send we end up discarding it. So what I
> am thinking is to enqueue the unsent messages and to maintain them on a
> queue until they are delivered with retry at configurable intervals.
>
> Thanks,
> Ger.
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
> f2368404.html
>
