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 17:01:28 GMT
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.
>
>

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