Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 67778 invoked from network); 4 Mar 2009 17:21:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 17:21:37 -0000 Received: (qmail 62324 invoked by uid 500); 4 Mar 2009 17:21:35 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 62310 invoked by uid 500); 4 Mar 2009 17:21:35 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 62283 invoked by uid 99); 4 Mar 2009 17:21:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 09:21:35 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 17:21:26 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LeumH-0006iR-VT for users@activemq.apache.org; Wed, 04 Mar 2009 09:21:05 -0800 Message-ID: <22334833.post@talk.nabble.com> Date: Wed, 4 Mar 2009 09:21:05 -0800 (PST) From: "A. Gregory Rabil" To: users@activemq.apache.org Subject: Re: Failover configuration for JMS clients using JNDI In-Reply-To: <36e91d9d0903040901w1f8bd95p67e6b420f070e9fb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: greg.rabil@ins.com References: <22332064.post@talk.nabble.com> <22332780.post@talk.nabble.com> <36e91d9d0903040822r32a868f7g181ab18f915b2bb7@mail.gmail.com> <22333686.post@talk.nabble.com> <36e91d9d0903040901w1f8bd95p67e6b420f070e9fb@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org 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 > 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 >> > 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: >> >> >> >> >> >> > >> >> >> >> uri="static:(failover:(ssl://broker-a:61617,ssl://broker-b:61617)?randomize=false)"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> James.Strachan wrote: >> >> > >> >> > 2009/3/4 A. Gregory Rabil : >> >> >> >> >> >> 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.