activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Posta <christian.po...@gmail.com>
Subject Re: How to detect a consumer's lost connection
Date Tue, 04 Jun 2013 17:01:23 GMT
The failover transport is an excellent choice for failing over to
alternative/standby brokers, however, when used with just one connection
URI, it will attempt to re-connect. You can set reconnection options
(backoff, timeout, etc) on it.

As for half-closed/uncleanly shutdown sockets, take a look at
WriteTimeoutFilter


On Mon, Jun 3, 2013 at 11:01 AM, Les Hazlewood <les@stormpath.com> wrote:

> I don't think this will address Mark's question (but Mark, please
> correct if I'm wrong).
>
> If I understand him correctly, he wants the client to know when Broker
> X is no longer available, and at that time, kill its current
> connection and then keep trying to automatically re-connect to Broker
> X until it is back online and available.
>
> The failover transport is primarily used to connect to a different
> broker (e.g. Broker Y) in the event that the currently connected
> broker fails, no?
>
> Also, could the behavior he is seeing be due to TCP socket timeout?  I
> have experienced problems with uncleanly shut-down sockets in the past
> and due to TCP keepalive, the client sometimes won't know the
> connection is dead for quite a while (e.g. default on Linux is I think
> 2 hours).  The only way to avoid this particular problem is to use a
> heartbeat mechanism.  Does ActiveMQ address this concern?
>
> I too would like to know how to auto-reconnect my consumers to the
> same broker as well, and here's why:
>
> Due to firewall issues, we have (potentially many) consumers that will
> use the HTTPS transport to connect to the broker through a load
> balancer.  We do failover swapping, restarts and such behind the load
> balancer, so the client doesn't need to be aware of multiple transport
> URLs.  They will only ever need a single HTTPS transport URL.  As
> such, how do I ensure that if a consumer loses a connection to the
> broker, they can continually try to auto-reconnect to the same
> transport URL?
>
> Thanks,
>
> Les
>
> On Sun, Jun 2, 2013 at 6:50 PM, SuoNayi <suonayi2006@163.com> wrote:
> > Just use the failover transport instead of your plain tcp transport,
> > it can reconnect to the broker transparently and it will replay
> > producers/consumers, the connection and pending transactions
> > when reconnection is successful.
> > http://activemq.apache.org/failover-transport-reference.html
> >
> >
> > At 2013-06-02 20:37:36,fenbers <Mark.Fenbers@noaa.gov> wrote:
> >>If ActiveMQ is restarted, we find that our producers and our consumers
> have
> >>to be shut down and relaunched in order to reestablish the connection
> with
> >>ActiveMQ.  This is a royal pain!  However, a producer will throw an
> >>exception whenever it tries to send a message through a lost connection,
> and
> >>so I catch the exception where I can close the connection and reopen it.
> >>Thus, my producers are able to reconnect automatically in the event
> ActiveMQ
> >>is restarted.
> >>
> >>But with a consumer, no exception is thrown as it waits for message
> >>notifications.  It simply waits eternally for a notification that never
> >>happens once a connection with ActiveMQ is lost.  So what is the
> recommended
> >>approach for a consumer to check for a disconnection??
> >>Mark
> >>
> >>
> >>
> >>--
> >>View this message in context:
> http://activemq.2283324.n4.nabble.com/How-to-detect-a-consumer-s-lost-connection-tp4667733.html
> >>Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



-- 
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta

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