activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: How to detect a consumer's lost connection
Date Sun, 09 Jun 2013 02:25:12 GMT
This is great.  Thanks for the follow up Christian!
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282


On Tue, Jun 4, 2013 at 10:01 AM, Christian Posta
<christian.posta@gmail.com> wrote:
> 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
View raw message