You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by fenbers <Ma...@noaa.gov> on 2013/06/02 14:37:36 UTC
How to detect a consumer's lost connection
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.
Re: How to detect a consumer's lost connection
Posted by Les Hazlewood <lh...@apache.org>.
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
<ch...@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 <le...@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 <su...@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 <Ma...@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
Re: How to detect a consumer's lost connection
Posted by Christian Posta <ch...@gmail.com>.
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 <le...@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 <su...@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 <Ma...@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
Re: How to detect a consumer's lost connection
Posted by Les Hazlewood <le...@stormpath.com>.
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 <su...@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 <Ma...@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.
Re:How to detect a consumer's lost connection
Posted by SuoNayi <su...@163.com>.
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 <Ma...@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.