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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>> >>>> >>>> >>>> >> >> >
