Forgot to mention that under ideal scenario I was hoping to consistently see
messages go to the same single consumer on either of the JVMs that registers
itself against same JMSXGroupId irrespective where the producer is.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Me
Hi All,
I am a newbie when it comes to networked brokers & active mq and need some
expert help.
I am trying to setup a system where messages order based JMSXGroupID is
preserved across networked brokers and concurrent consumers. In the use
case i have 2 JVMs that each have 10 concurrent consumers
Thank you, Martin,
this is indeed a result of heap dump analysis. Under normal conditions the
application
operates happilly with around 800MB of heap as can be seen in visualvm. In
these out
of memory situations, 1.2 - 1.6 GBs is allocated in that very object in the
description.
It is always this
Sent from my BlackBerry 10 smartphone.
Original Message
From: Martin Herrman
Sent: Thursday, August 4, 2016 17:44
To: users@activemq.apache.org
Reply To: users@activemq.apache.org
Subject: Re: Messages piling up in FailoverTranport
Hi Patrik,
My approach would be to gather more information
Hi Patrik,
My approach would be to gather more information about the memory usage. A
method is to enable JMX and use VisualVM to create the graphs. These links
might help:
http://blog.payara.fish/troubleshooting-your-java-ee-applications
https://visualvm.java.net/monitor_tab.html
HTH,
Martin
Hello,
I'm facing a situation where client go OutOfMemory due to ever growing
transaction log in
FailoverTransport.stateTracker.connectionStates[one specific
connection].transactions.
The majority of recorded transactions contain three commands:
1. TransactionInfo BEGIN
2. The message the client
Hi Tim and Christopher,
Thanks both for your very quick response. For now I decided to just stop
ActiveMQ, remove the store, and start ActiveMQ again. I believe that this is a
very acceptable solution in our case, but I will check with the team before we
update our production systems.
Thanks
Between those 2 versions the open OpenWire version used was upgraded as you
saw. This is not an issue when starting with a fresh store but as you are
seeing, when you upgrade from an existing store you will have old journal
files with messages laying around that were written using the older
OpenWi
Is doesn't resolve the question of why the index rebuild doesn't work, but
one path forward is to stand up a new broker with an empty KahaDB store and
then stand up this one with a networkConnector to the new one. Have all
clients connect to the new (empty) broker, which will be using the new
mess
Dear ActiveMQ users,
I just upgraded our ActiveMQ deployment from release 5.11.1 to 5.13.4 (I'm on
Ubuntu 14.04.5), which went pretty smooth. On this server ActiveMQ has been
updated many times so I was not surprised to get this in the logs during
startup:
WARN | Existing Store uses a differe
10 matches
Mail list logo