I am using a multi-threaded client of JbossMQ which does the following:
1.) Creates a Connection on the main thread
2.) Spawns n client threads. On start, each client thread then aquires a Session from the Connection, and a MessageConsumer from the Session it created. Once the MessageConsumer is created the thread goes into a loop calling receive() on the MessageConsumer. Note that all of this has quite possibly occured before calling start() on the Connection. All this should be allowed by the spec as Connection is a thread safe object.
3.) Calls Connection.start() on the main thread.
The problem I am seeing is that I intermittently get
javax.jms.JMSException: The provided subscription does not exist
at org.jboss.mq.server.ClientConsumer.getSubscription(ClientConsumer.java:365)
at org.jboss.mq.server.JMSDestinationManager.getSubscription(JMSDestinationManager.java:867)
at org.jboss.mq.server.JMSServerInterceptorSupport.getSubscription(JMSServerInterceptorSupport.java:319)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:96)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:535)
...
Looking through the code of the interceptor stack, I believe the problem to be in the JMSDestinationManager. For several operations, including adding a MessageConsumer, it calls the method getClientConsumer(ConnectionToken tok). This method lazily creates a ClientConsumer for a given connection token the first time it is called for the connection token. This method is not synchronized in any way, so I'm guessing adding multiple MessageConsumer simultaneously triggers the creation of multiple ClientConsumer objects due to this lack of synchronization. This then leads to the stack trace above since the ClientConsumer cached for the connection token does not have all the subscriptions, since some subscriptions were mistakenly created on other ClientConsumers due to the race condition.
Is there some sort of synchronization going on here that I'm missing or is this a bug?
