[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    Re: rebalanceClusterClients , failover and transactions
From:       Gary Tully <gary.tully () gmail ! com>
Date:       2014-02-21 10:22:19
Message-ID: CAH+vQmNAYA+q8c9HY_4bDYZ7PzGznHPNmhL73vqib70sAw_hMg () mail ! gmail ! com
[Download RAW message or body]


Peek at this test and that package
https://github.com/apache/activemq/blob/trunk/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/ThreeBrokerQueueNetworkUsingTcpTest.java
 On 21 Feb 2014 06:26, "Enrico Olivelli" <eolivelli@gmail.com> wrote:

> 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
> > > > > 
> > > > 
> > > > 
> > > > 
> > 
> > 
> 



[prev in list] [next in list] [prev in thread] [next in thread]