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.

Reply via email to