You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by ronK <Ro...@Seagate.com> on 2006/11/01 00:46:26 UTC

Failover Protocol

I am looking for a way to have my clients failover to alternate brokers, use
asynchronous sends, and keep my client code vanilla JMS.
It appears you can't use the failover transport and set connection
properties via the uri at the same time. What I would like to do is combine
failover:(tcp://localhost:61616,tcp://remotehost:61616) with
tcp://localhost:61616?jms.useAsyncSend=true but it doesn't seem to work.
i.e.
failover:(tcp://localhost:61616?jms.useAsyncSend=true,tcp://remotehost:61616?jms.useAsyncSend=true)
Anyone know if this is supposed to work?

The documentation says:
"The good news is that ActiveMQ sends message in async mode by default in
several cases. It is only in cases where the JMS specification required the
use of sync sending that we default to sync sending. The cases that we are
forced to send in sync mode are when persistent messages are being sent
outside of a transaction."

This doesn't appear to be entirely true because when I attempt to use the
NON_PERSISTENT mode, send() still blocks if no brokers are available. When
this happens I can't shut the program down or notify anyone there is a
problem. Note, the ttl of the message can expire and the send() remains
blocked. If I could somehow stop the send() I could have another thread
monitor it and stop it if necessary. Lots of things seem to block that
shouldn't, you can't build robust software if you can't shut things down and
restart them when you suspect something is out of wack.

Ron 
-- 
View this message in context: http://www.nabble.com/Failover-Protocol-tf2549326.html#a7105422
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Failover Protocol

Posted by ronK <Ro...@Seagate.com>.
Combining failover and asynchronous sends as suggested doesn't work either,
it appears only failover configuration items are expected there. Limiting
the retry count worked great, the send returns quickly when a broker is not
available. This allows me to restart things, shut down the application,
and/or notify someone there is a problem.

Adrian Co wrote:
> 
> Hi,
> 
> Try:
> failover:(tcp://remotehost:61616,tcp://localhost:61616)?jms.useAsyncSend=true
> 
> Regarding the blocking part:
> It could be blocking because of the failover transport, as it keeps 
> retrying to connect to one of the brokers. I'd try setting the retry 
> count and the retry interval to a smaller value.
> 
> 
> ronK wrote:
>> I am looking for a way to have my clients failover to alternate brokers,
>> use
>> asynchronous sends, and keep my client code vanilla JMS.
>> It appears you can't use the failover transport and set connection
>> properties via the uri at the same time. What I would like to do is
>> combine
>> failover:(tcp://localhost:61616,tcp://remotehost:61616) with
>> tcp://localhost:61616?jms.useAsyncSend=true but it doesn't seem to work.
>> i.e.
>> failover:(tcp://localhost:61616?jms.useAsyncSend=true,tcp://remotehost:61616?jms.useAsyncSend=true)
>> Anyone know if this is supposed to work?
>>
>> The documentation says:
>> "The good news is that ActiveMQ sends message in async mode by default in
>> several cases. It is only in cases where the JMS specification required
>> the
>> use of sync sending that we default to sync sending. The cases that we
>> are
>> forced to send in sync mode are when persistent messages are being sent
>> outside of a transaction."
>>
>> This doesn't appear to be entirely true because when I attempt to use the
>> NON_PERSISTENT mode, send() still blocks if no brokers are available.
>> When
>> this happens I can't shut the program down or notify anyone there is a
>> problem. Note, the ttl of the message can expire and the send() remains
>> blocked. If I could somehow stop the send() I could have another thread
>> monitor it and stop it if necessary. Lots of things seem to block that
>> shouldn't, you can't build robust software if you can't shut things down
>> and
>> restart them when you suspect something is out of wack.
>>
>> Ron 
>>   
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Failover-Protocol-tf2549326.html#a7144086
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: Failover Protocol

Posted by Adrian Co <ac...@exist.com>.
Hi,

Try:
failover:(tcp://remotehost:61616,tcp://localhost:61616)?jms.useAsyncSend=true

Regarding the blocking part:
It could be blocking because of the failover transport, as it keeps 
retrying to connect to one of the brokers. I'd try setting the retry 
count and the retry interval to a smaller value.


ronK wrote:
> I am looking for a way to have my clients failover to alternate brokers, use
> asynchronous sends, and keep my client code vanilla JMS.
> It appears you can't use the failover transport and set connection
> properties via the uri at the same time. What I would like to do is combine
> failover:(tcp://localhost:61616,tcp://remotehost:61616) with
> tcp://localhost:61616?jms.useAsyncSend=true but it doesn't seem to work.
> i.e.
> failover:(tcp://localhost:61616?jms.useAsyncSend=true,tcp://remotehost:61616?jms.useAsyncSend=true)
> Anyone know if this is supposed to work?
>
> The documentation says:
> "The good news is that ActiveMQ sends message in async mode by default in
> several cases. It is only in cases where the JMS specification required the
> use of sync sending that we default to sync sending. The cases that we are
> forced to send in sync mode are when persistent messages are being sent
> outside of a transaction."
>
> This doesn't appear to be entirely true because when I attempt to use the
> NON_PERSISTENT mode, send() still blocks if no brokers are available. When
> this happens I can't shut the program down or notify anyone there is a
> problem. Note, the ttl of the message can expire and the send() remains
> blocked. If I could somehow stop the send() I could have another thread
> monitor it and stop it if necessary. Lots of things seem to block that
> shouldn't, you can't build robust software if you can't shut things down and
> restart them when you suspect something is out of wack.
>
> Ron 
>