You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "A. Gregory Rabil" <gr...@ins.com> on 2009/03/04 16:15:24 UTC
Failover configuration for JMS clients using JNDI
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
# use the following property to specify the JNDI name the connection factory
# should appear as.
connectionFactoryNames = LocalActiveMqConnectionFactory,
ActiveMqConnectionFactory
connection.LocalActiveMqConnectionFactory.url = tcp://localhost:61616
connection.ActiveMqConnectionFactory.url =
failover:(ssl://broker-a:61617,ssl://broker-b:61617)?randomize=false
When my client used the ActiveMqConnectionFactory to connect to the remote
broker, it connects to Broker A if Broker A is available when the client
connects. However, if Broker A is not available, it never attempts to
connect to Broker B. Also, if connected to Broker A, and Broker A is
stopped, the client does not successfully "failover", instead I just get
this in the client's log:
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
Please let me know what I need to configure to get this behavior to work, as
this seems to be a fairly simple test of the "failover" transport, yet I
can't seem to get a successful test.
Thank you,
Greg Rabil
--
View this message in context: http://www.nabble.com/Failover-configuration-for-JMS-clients-using-JNDI-tp22332064p22332064.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Failover configuration for JMS clients using JNDI
Posted by "A. Gregory Rabil" <gr...@ins.com>.
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 <gr...@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-tp22332064p22332790.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Failover configuration for JMS clients using JNDI
Posted by "A. Gregory Rabil" <gr...@ins.com>.
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 <gr...@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 <gr...@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 <gr...@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.
Re: Failover configuration for JMS clients using JNDI
Posted by Dejan Bosanac <de...@nighttale.net>.
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 <gr...@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 <gr...@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 <gr...@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.
>
>
Re: Failover configuration for JMS clients using JNDI
Posted by "A. Gregory Rabil" <gr...@ins.com>.
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 <gr...@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 <gr...@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.
Re: Failover configuration for JMS clients using JNDI
Posted by Dejan Bosanac <de...@nighttale.net>.
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 <gr...@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 <gr...@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.
>
>
Re: Failover configuration for JMS clients using JNDI
Posted by "A. Gregory Rabil" <gr...@ins.com>.
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 <gr...@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.
Re: Failover configuration for JMS clients using JNDI
Posted by James Strachan <ja...@gmail.com>.
2009/3/4 A. Gregory Rabil <gr...@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/