activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ronK <>
Subject Re: Failover Protocol
Date Thu, 02 Nov 2006 19:14:28 GMT

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:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message