activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosmin Petre Florea <fosminclo...@gmail.com>
Subject ActiveMQ advisory message and failover
Date Wed, 07 Oct 2020 12:46:26 GMT
Hi,

  We are using ActiveMQ C++ library with failover transport. We have:

  - 2  brokers configured in "shared file system master slave" (only 1 
is active at a time)

-  2 clients connected to the active broker Broker_1:

     Client_1 has a consumer for |ActiveMQ.Advisory.Consumer.Topic|

     Client_2 has a consumer C2 for Topic_2;

  When Client_1 finds out that C2 is no longer a consumer on Topic_2 
(via ConsumerInfo/RemoveInfo), Client_1 assumes that Client_2 has 
suddenly died and stops communication with Client_2. We want that to 
happens only when Client_2 is down.

  If the Broker_1 is up and Client_2 stops, Client_1 receives the 
RemoveInfo and everything OK.

  if Broker_1 goes down and Client_1 and Client_2 keep running but move 
to Broker_2, then Client_1 receives a RemoveInfo + ConsumerInfo for C2 
and the  content of the advisory is the same as when the Client_2 
actually went down  (we don't know by just reading the Advisory message 
if the broker went down or the client went down).

We noticed that, at failover, we receive in Client_1 first a RemoveInfo, 
then a TransportListener::transportInterrupted() so in order to "ignore" 
the RemoveInfo , we don't process it when it arrives, but wait (N 
milliseconds) to see if transportInterrupted() is called too. This works 
almost all the time, only that under heavy loads the distance in time 
between the 2 events tends to get bigger than our configured N 
(sometimes more than 3 seconds), so maybe we need something else.

Do you know of any approach to distinguish between a client failure and 
a broker failure when failover is activated? Is there a "separated" 
channel for advisory messages or they are sent in the same stream as 
regular data? How reliable are the advisory messages sent during 
failover - should we always expect a RemoveInfo+ConsumerInfo (sometimes 
we don't receive the ConsumerInfo, don't know if bug in our application)?

Thank you,

Cosmin



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message