|
The attached test case fails for me everytime. I can get it to not fail by sleeping a bit before the conn.start() call, so its obviously a problem related to connection starting concurrently with one of the other operations in the other thread. This is against a single broker.
I have analysed the way Spring is using/setting clientID, and in short, it isnt unless I tell it to. Im only opening one connection anyway, and you can see just one connection in the test case i provided. Switching to another JMS provider with the same code/config works fine. I'm wondering if this is a timing issue between one thread calling connection.start() and another calling createSession().
Maybe it only fails on your OS, processor & JVM etc? Some further information for you. I attached a debugger to the broker and the testcase. Here is the problem: The testcase calls createSession() resulting in the following stack of calls: wait():-1, java.lang.Object on the server this ends up at: addConnection():148, org.apache.activemq.broker.region.RegionBroker where RegionBroker adds the generated clientID to the clientIDSet. Note that I havent called conn.start() yet! The main thread then calls conn.start() resulting in the following stack of calls: wait():-1, java.lang.Object i.e. another call to ensureConnectionInfoSent()!!! resulting in the broker stack of calls: addConnection():148, org.apache.activemq.broker.region.RegionBroker where the clientID is checked and collides with the clientID deposited from the first call. Its pretty obvious looking at it that ensureConnectionInfo() and the setting of the boolean /**
if (info.getClientId() == null || info.getClientId().trim().length() == 0) {
info.setClientId(clientIdGenerator.generateId());
} this.isConnectionInfoSentToBroker = true; ConsumerId consumerId = new ConsumerId(new SessionId(info.getConnectionId(), -1),consumerIdGenerator.getNextSequenceId()); } Great catch Craig - thanks for figuring all that out - I was starting to suspect something like this could be the cause of your error.
I've made the ensureConnectionInfoSent() method synchronized now so that this loophole should be now fixed. Could you test its working for you now please? Let us know if its not and we can reopen this issue fyi I ran into the very same issue with 4.0 RC3. After upgrading to the 4.0 release jar (dated jun 13, 2006), I no longer see this error.
oops, looks like I spoke too soon. With Active MQ 4.0 RC3, I used to get this exception as soon as the brokers were started. However with 4.0 final, on startup this exception does not occur. It shows up when messages are received by the broker. I'm using Spring-2.0 with DefaultMessageListenerContainer as well.
Here's the stacktrace : 2006-06-15 22:06:35,017 INFO [org.apache.activemq.broker.AbstractConnection.Service] - <Sync error occurred: javax.jms.InvalidClientIDException: Broker: localhost - Client: ID:weston-2030-1150416833580-1:0 already connected> Sanjiv - can you provide some kind of test case to demonstrate the problem - I'm not sure what you are doing and generally don't use the Spring DefaultMessageListenerContainer
I've created a separate issue : http://issues.apache.org/activemq/browse/AMQ-760
 and uplaoded a test app to demonstrate this and some other issues as well. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Client: XXX already connected exception when connection started after consumers added
https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/bugs/CraigsBugTest.java
and unfortunately it works perfectly.
I suspect the bug is caused by Spring reusing a clientID on 2 JMS connections? Can you get a JUnit test case to fail by itself? I suspect some other node in the network is causing the problem, not this test case