I also faced this issue. I am using ActiveMQv5.14.
Steps to reproduce:
* Connect a durable consumer with some client-id say CLIENT1
* Start another durable consumer with same client-id (CLIENT1)
* Stop the first consumer.
We expected that second consumer should get connected automatically bu
Hmmm, interesting. That means one of two things:
1. Following the broker restart, multiple client processes/threads are
trying to connect using the same client ID. For a given client ID, the
first process/thread to attempt the connection will succeed, and the later
ones will fail. I would expect t
> Does restarting the broker without enabling link stealing also let you work
> around the problem?
Unfortunately No. Restarting broker also doesn't solve the problem. Only
when you restart it with link stealing resolves the issue.
Thanks,
Anuj
--
Sent from: http://activemq.2283324.n4.nabble.
Does restarting the broker without enabling link stealing also let you work
around the problem? Based on what you've described as working vs. not, I
would expect that to be a viable workaround. And if it's not, that might
give more information about what's actually going on.
Tim
On Sep 27, 2017 1
Hi,
This problem is non-reproducible. I have tried many times with different
configuration but not able to reproduce it. Even our clients using ActiveMQ
sometimes face this suddenly in prod environment where dev/qa works fine.
The worst part about this issues is to fix it. This does not get resol
I finally got time on a computer (not my phone) to look at this.
First, the reason that you're not seeing a stack trace is our fault, not
the result of the JVM optimizing away the stack trace. If you look at line
858 of
https://github.com/apache/activemq/blob/activemq-5.14.x/activemq-broker/src/ma
I can only see warning message in broker logs:
[2017-09-16 14:15:59.540-0400] [ActiveMQ NIO Worker 3]
[org.apache.activemq.broker.TransportConnection] [WARN]
[TransportConnection.java:org.apache.activemq.broker.TransportConnection:processAddConnection()::858]
[Failed to add Connection
id=ID:
Do you get a stack trace after that line in the logs? I spent a small
amount of time trying to figure out where that InvalidClientIDException is
thrown so I could look at why that null might be getting in there, but it
wasn't immediately obvious so a stack trace would help.
Note that the JRE will
Any reason why this is happening? It says connected from "NULL" ? Sounds like
a bug.
Thanks,
Anuj
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
On 09/18/2017 10:25 AM, khandelwalanuj wrote:
Hi,
I am using ActiveMQv5.14.
We observed issues with durable java subscribers using TCP connector that
lot of time after client/broker restart clients were not able to connect
back to the broker and see below exception *"connected from null"*
Lot
Hi,
I am using ActiveMQv5.14.
We observed issues with durable java subscribers using TCP connector that
lot of time after client/broker restart clients were not able to connect
back to the broker and see below exception *"connected from null"*
Lot of time after client restart, we get below exce
11 matches
Mail list logo
