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
