activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: rebalanceClusterClients , failover and transactions
Date Fri, 21 Feb 2014 06:25:55 GMT
thanks, I'll try to write down a test case to reproduce my duplicate 
message issue on transactions
Can you tell me a sample test case to copy from in order to get started 
? I think I have to start a little network of brokers inside one single 
JVM in order to reproduce the problem
thank you

Il 19/02/2014 13:39, Gary Tully ha scritto:
> inline
>
> On 16 February 2014 16:09, Enrico Olivelli <eolivelli@gmail.com> wrote:
>> If I set updateURIsSupported=false do I need to reconfigure all the clients
>> when I'm going to a a new broker ?
> yes. you could make use of updateURIsURL to externalise the list.
>
>> I cannot find the documentation for reconnectSupported here
>> http://activemq.apache.org/failover-transport-reference.html
>> what does that option mean ?
> it causes failover to ignore reconnect commands from the broker. I
> updated the doc to include this.
>
>> I do not understand clearly what is the maning of |priorityBackup while
>> using the updateClusterClients features, that it, in a network of brokers
>> where clients discover the existance of new brokers from informations
>> received from the actually connected broker and do not necessarly known the
>> URLs of every broker at startup
> It is static, so not much use if you don't know the possible broker
> url list up front. Possibly
> this can be made more general, like a regx match rather than an exact
> match like it is today.
> That may be a sensible enhancement, please open a jira if you think it
> would help your scenario.
>
>
> On the real issue with transactions and failover. In general a
> failover can occur at any time,
> so dealing with a rebalance reconnect is no different.
> When you say messages are suppressed as duplicates - do they get lost.
> if so then we have a problem
> broker side that we need to address.
>
> If you can provide a test case that warrants a jira to investigate some more.
>
>> can you explain ?
>> |
>> thank you very much
>>
>>
>> Il 14/02/2014 15:52, Gary Tully ha scritto:
>>
>>> the rebalance is all about new brokers in the cluster, so the
>>> rebalance should only fire on a broker start.
>>>
>>> the priorityBackup options allow a failover client to be sticky. Also
>>> updateURIsSupported=false and reconnectSupported=false disables this
>>> feature client side
>>>
>>> On 8 February 2014 17:07, Enrico Olivelli <eolivelli@gmail.com> wrote:
>>>> Hi,
>>>> I'm facing a problem in my system due to the option
>>>> rebalanceClusterClients.
>>>> As I can see when this option is enabled every time a new connection is
>>>> created a signal is sent to every connected client in the network and
>>>> every
>>>> failover connection is closed and re-opened.
>>>> In my system it happens that when a producer (using failover tranport) is
>>>> inside a transaction and a new client connects then some of the messages
>>>> are
>>>> dropped by KahaDB as beeing ssen as duplicates
>>>>
>>>> Again, the rebalanceClusterClients option is very aggressive and
>>>> generates a
>>>> lot of network/broker overhead in my system, when I have something like
>>>> 100
>>>> cons JVM , which get disconnected and reconnected every time a new
>>>> producer
>>>> (which is sporadically spawned) gets in.
>>>>
>>>> Can I realize a setup like this ?
>>>> - failover transport producers insiede a transaction do not
>>>> accept/silently
>>>> drop  the command to rebalance the cluster and reconnect
>>>> - not every client get reconnected at every new client attaches to the
>>>> cluster
>>>>
>>>> thanks in advance
>>>> ActiveMQ is great
>>>>
>>>>
>>>> Enrico Olivelli
>>>
>>>
>
>


Mime
View raw message