You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Miguel <mi...@gmail.com> on 2011/01/11 18:54:52 UTC

Re: broker config if destination may be down

I have the same problem: if one don't want the broker A to block at startup
if a remote broker B is not reachable, the "startupMaxReconnectAttempts"
parameter must be used, but A won't try to connect to B anymore, so all
messages will be queued in A until it's restarted. Is there any workaround?
-- 
View this message in context: http://activemq.2283324.n4.nabble.com/broker-config-if-destination-may-be-down-tp3086163p3209402.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: broker config if destination may be down

Posted by JoeC <jo...@gmail.com>.
Miguel - can you post example code for your solution?
I'm suffering the same problem but get JMSExceptions when I try to add a
JmsQueueConnector dynamically after broker startup.
The case where the server fails after client connection is ok but not the
initial startup.

As a side note I'm rather surprised activemq doesn't handle what I thought
would be a common use case where a client buffers messages without blocking
until the remote broker is available.
I don't see why the bridge connectors should block the local broker start
up.
-- 
View this message in context: http://activemq.2283324.n4.nabble.com/broker-config-if-destination-may-be-down-tp3086163p3225420.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: broker config if destination may be down

Posted by Miguel <mi...@gmail.com>.
Well, I found the solution for my use case: 
1) server A starts up without any bridge connector configured.
2) In a thread, a bridge connector is configured for server B, which is not
started yet. The url is "failover:(tcp://x.x.x.x:yyyyy)". The thread will
block until server B is reachable.
3) Messages for the not-yet-started connector are queued
4) Server B is started
5) After some time, the retrying thread connects to server B and delivers
all the queued messages

So, at least for this use case, it's working OK.
-- 
View this message in context: http://activemq.2283324.n4.nabble.com/broker-config-if-destination-may-be-down-tp3086163p3209448.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.