activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SuoNayi <suonayi2...@163.com>
Subject Reply:Re: Reply:failover transport connect
Date Wed, 23 Jan 2013 05:26:46 GMT
Yes, I know your purpose with that setting.
After taking a glance through the source code of 5.5.x, I'm afraid that
the client will do rebalance when connection control messages arrive.
You can disable rebalanceClusterClients option on TransportConnector 
and try again to verify whether your issue is caused by combination options
I mentioned.




At 2013-01-23 13:01:56,"Nate Faerber" <nate.faerber@itsoninc.com> wrote:
>I set randomize to false expecting the clients to connect to the first mq
>server.  In that case, the clients wouldn't need to rebalance.  I see this
>on the first mq server but I feel like this is a result of the client
>bouncing over to the failover rather than it being the reason it bounces
>over to the failover.  The servers should be identical in configuration so
>the fact that one is failing is strange.  I actually see this on both MQ
>servers now that I look at the logs of both.
>
>2013-01-22 20:57:35,764 | WARN  | Transport Connection to: tcp://
>10.232.2.137:58155 failed: java.io.EOFException |
>org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ
>Transport: tcp:///10.232.2.137:58155@61616
>
>I must have a fundamental configuration issue.  Any ideas how I can
>troubleshoot this better?
>
>Thanks,
>
>--
>Nate Faerber
>Senior Systems Engineer, Operations
>ItsOn, Inc.
>desk: 650.517.2785
>mobile: 415.794.2731
>{us/pacific}
>
>
>On Tue, Jan 22, 2013 at 12:39 AM, SuoNayi <suonayi2006@163.com> wrote:
>
>> Hi, I guess:
>> 1. The broker sends the rebalance control messages to your client and your
>> client do rebalance and reconnect to the other broker;
>> 2. The second broker has some consumers while none on the first broker
>> so messages sent to the first broker are forwarded to the second broker by
>> demand.
>> 3. Failover transport may misbehave in your case where enabling
>> rebalanceClusterClients
>> option of TransportConnector and backup option of FailoverTransport while
>> disabling
>> randomize option of FailoverTransport .
>>
>>
>>
>>
>>
>> At 2013-01-22 12:24:27,"Nate Faerber" <nate@itsoninc.com> wrote:
>> >Hi,
>> >
>> >I have two ActiveMQ server configured as network of brokers and my clients
>> >with this connect string:
>> >
>>
>> >failover:(tcp://mq1-master:61616,tcp://mq2-master:61616)?randomize=false&backup=true&maxReconnectDelay=10000
>> >
>> >It seems that every time we create a JMS message using Spring Framework,
>> >the ActiveMQ connection, our clients try the primary then fail to the
>> >secondary.  The large (large) majority of messages go through the second
>> >ActiveMQ server.  This seems like an inefficiency or at least does not
>> >behave like I would expect it to.  Am I misunderstanding the configuration
>> >here?
>> >
>> >2013-01-21 20:10:27,604 INFO
>> > [org.apache.activemq.transport.failover.FailoverTransport][ActiveMQ
>> >Task-1] [FailoverTransport.java:1030] Successfully connected to
>> >tcp://mq1-master:61616
>> >2013-01-21 20:10:27,610 INFO
>> > [org.apache.activemq.transport.failover.FailoverTransport][ActiveMQ
>> >Task-1] [FailoverTransport.java:1032] Successfully reconnected to
>> >tcp://mq2-master:61616
>> >
>> >My servers have this config:
>> >
>> >        <transportConnectors>
>> >            <transportConnector
>> >                name="${broker.transport.client.name}"
>> >                uri="${broker.transport.client.uri}"
>> >                updateClusterClients="true"
>> >                updateClusterClientsOnRemove="true"
>> >                rebalanceClusterClients="true" />
>> >
>> >            <transportConnector
>> >                name="${broker.transport.network.name}"
>> >                uri="${broker.transport.network.uri}" />
>> >        </transportConnectors>
>> >
>> >Thoughts appreciated.
>> >
>> >thanks,
>> >-nate
>>

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