activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <de...@nighttale.net>
Subject Re: Failover configuration for JMS clients using JNDI
Date Wed, 04 Mar 2009 16:22:00 GMT
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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message