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 16:34:37 GMT

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
View raw message