activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Gregory Rabil" <greg.ra...@ins.com>
Subject Re: Failover configuration for JMS clients using JNDI
Date Wed, 04 Mar 2009 17:21:05 GMT

Dejan,
Thank you for this suggestion.  Wish I tried that earlier... it turns out
that I had a typo on the IP address of my Broker B in the jndi.properties. 
So, with debugging on, I saw that the Failover transport tried to failover
to Broker B (at the wrong IP), and kept getting "connection refused"... doh!

Thanks again,
Greg


Dejan Bosanac wrote:
> 
> Hi,
> 
> can you try turning debugging for failover transport in your application,
> so
> you can get more details on what is going on?
> 
> Cheers
> --
> Dejan Bosanac
> 
> Open Source Integration - http://fusesource.com/
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
> 
> 
> On Wed, Mar 4, 2009 at 5:34 PM, A. Gregory Rabil <greg.rabil@ins.com>
> wrote:
> 
>>
>> Hi Dejan,
>> No, my application does not terminate.  It is still running.  What I get
>> is
>> this:
>>
>> 2009-03-04 15:09:04,221 ()[ActiveMQ Transport: ssl:///broker-a:61617]
>> WARN
>> FailoverTransport - Transport failed to ssl://broker-a:61617 , attempting
>> to
>> automatically reconnect due to: java.io.EOFException
>> 2009-03-04 15:09:04,222 ()[ActiveMQ Transport: ssl:///broker-a:61617]
>> WARN
>> FailoverTransport - Transport failed to ssl://broker-a:61617 , attempting
>> to
>> automatically reconnect due to: java.io.EOFException
>>
>> Which seems to indicate that the failover transport has determined the
>> situation and attempts to "failover", but that never happens.
>>
>> When I stop Broker A, then I see that Broker C automatically connects to
>> Broker B, as configured in my networkConnector.  Basically, I want the
>> same
>> behavior for my client using the connectionFactory.  In fact, I had this
>> configuration working in AMQ 4.1.1, although in that version, I had to
>> patch
>> the DemandForwardingBridgeSupport class with the following:
>>
>> The original code, beginning at line 178:
>>                    lastConnectSucceeded.set(false);
>>
>>                    log.debug("Outbound transport to " + remoteBrokerName
>> +
>> " resumed");
>>                }
>>            }
>>        });
>>        localBroker.start();
>>        remoteBroker.start();
>>
>>
>> The patched 4.1.1 code, beginning at line 178:
>>                    lastConnectSucceeded.set(false);
>>
>>                    log.debug("Outbound transport to " + remoteBrokerName
>> +
>> " resumed");
>>
>>                    try{
>>                        localBroker.start();
>>                        remoteBroker.start();
>>                        triggerRemoteStartBridge();
>>                    }catch(Exception e){
>>                        log.warn("Caught exception from remote
>> restart",e);
>>                    }
>>                }
>>            }
>>        });
>>        localBroker.start();
>>        remoteBroker.start();
>>
>> This code is a bit different in 5.2.0, and actually looks as if it is
>> trying
>> to do something similar to what my patch did.
>>
>> Thanks again.  Any other pointers that you can provide?
>> Greg
>>
>>
>>
>> Dejan Bosanac wrote:
>> >
>> > Hi Gregory,
>> >
>> > it looks to me that your application terminates before failover
>> recovery
>> > thread is started. In a usual application this will not happen since
>> the
>> > application will have more logic into it. Try preventing your
>> application
>> > to
>> > stop, by starting a dummy thread or something like that and see if it
>> > helps.
>> >
>> > Cheers
>> > --
>> > Dejan Bosanac
>> >
>> > Open Source Integration - http://fusesource.com/
>> > ActiveMQ in Action - http://www.manning.com/snyder/
>> > Blog - http://www.nighttale.net
>> >
>> >
>> > On Wed, Mar 4, 2009 at 4:53 PM, A. Gregory Rabil <greg.rabil@ins.com>
>> > wrote:
>> >
>> >>
>> >> Hi James,
>> >> I should clarify my setup:
>> >>
>> >> Broker A: has a local client which produces messages for a task queue,
>> >> and
>> >> another local client that consumes messages from a result queue.
>> >>
>> >> Broker B: a warm-standby of broker A, with local producer and local
>> >> consumer
>> >> as in Broker A.
>> >>
>> >> Broker C: has a local client which consumes messages from the task
>> queue,
>> >> and produces messages on the result queue.  The task messages are
>> >> consumed
>> >> by this client by connecting to Broker A (or B) and receiving.  The
>> >> result
>> >> messages are produces on the local Broker C, to be
>> stored-and-forwarded
>> >> to
>> >> Broker A (or B), where the consumer of the result queue lives.
>> >>
>> >> I want my client on the Broker C machine to use its local, Broker C,
>> for
>> >> JNDI resolution of connection and queue names.  However, I want it to
>> >> "connect" to either Broker A (or B) to actually receive messages.
>> >>
>> >> I'm confused why I would need to specify "failover" for the JNDI
>> >> provider?
>> >> I am simply looking for the actual JMS client connection to failover,
>> the
>> >> JNDI provider in the local Broker C can be assumed to be always
>> available
>> >> from the perspective of this client.  The way my application works,
>> the
>> >> client on Broker C is dependent upon Broker C being available.  I want
>> >> this
>> >> so that even in the event that I can't talk to either Broker A or B, I
>> >> still
>> >> want to be able to process any tasks that I have already received, and
>> >> still
>> >> be able to post messages to the local broker to be
>> stored-and-forwarded
>> >> later, when the connection is re-established.
>> >>
>> >> The configuration of my Broker C looks like this:
>> >>
>> >>    <networkConnectors>
>> >>      <networkConnector name="incx-broker"
>> >>
>> >>
>> uri="static:(failover:(ssl://broker-a:61617,ssl://broker-b:61617)?randomize=false)">
>> >>
>> >>        <staticallyIncludedDestinations>
>> >>                <queue physicalName="ResulteQueue"/>
>> >>        </staticallyIncludedDestinations>
>> >>
>> >>      </networkConnector>
>> >>
>> >>
>> >>
>> >>
>> >> James.Strachan wrote:
>> >> >
>> >> > 2009/3/4 A. Gregory Rabil <greg.rabil@ins.com>:
>> >> >>
>> >> >> Hello,
>> >> >> I'm using ActiveMQ 5.2.0, and I'm trying to configure a simple
test
>> of
>> >> >> the
>> >> >> "failover" transport.  I have two brokers A and B, and a JMS client
>> on
>> >> a
>> >> >> remote machine.  I want the client to connect to Broker A, unless
>> it
>> >> is
>> >> >> unavailable, in which case it should connect to Broker B. 
>> Likewise,
>> >> if
>> >> >> the
>> >> >> client is connected to Broker A, and Broker A crashes, or the
>> client
>> >> >> otherwise loses connection to Broker A, I want it to failover to
>> >> Broker
>> >> >> B.
>> >> >> Here is my jndi.properties file for the JMS client:
>> >> >>
>> >> >> java.naming.factory.initial =
>> >> >> org.apache.activemq.jndi.ActiveMQInitialContextFactory
>> >> >>
>> >> >> # use the following property to configure the default connector
>> >> >> java.naming.provider.url = tcp://localhost:61616
>> >> >
>> >> > Did you try changing this property to use failover?
>> >> > java.naming.provider.url =
>> >> > failover:(ssl://broker-a:61617,ssl://broker-b:61617)?randomize=false
>> >> >
>> >> > --
>> >> > James
>> >> > -------
>> >> > http://macstrac.blogspot.com/
>> >> >
>> >> > Open Source Integration
>> >> > http://fusesource.com/
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Failover-configuration-for-JMS-clients-using-JNDI-tp22332064p22332780.html
>> >> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > -----
>> > Dejan Bosanac
>> >
>> > Open Source Integration - http://fusesource.com/
>> > ActiveMQ in Action - http://www.manning.com/snyder/
>> > Blog - http://www.nighttale.net
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Failover-configuration-for-JMS-clients-using-JNDI-tp22332064p22333686.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
> 
> 
> -----
> Dejan Bosanac
> 
> Open Source Integration - http://fusesource.com/
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
> 

-- 
View this message in context: http://www.nabble.com/Failover-configuration-for-JMS-clients-using-JNDI-tp22332064p22334833.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message