We’ve created a document-type in Enterprise server, and created a Java client that publishes that document through JMS. This works fine as long as there is one client that publishes, but as soon as we try to start more than one client-program that publishes messages through JMS simultaneously we get the following error:
“Client Contention (201-1030): Cannot reconnect client ‘JMS_BCIntegration1’. Another process is already connected to the broker and is using this client.”
How can we solve this problem ? As the publisher will be a stateless EJB we need to support more than one publisher.
You need to change the client name you use to connect to something that will be unique for each invocation of the stateless EJB.
From your post I am guessing that you are using a jms implementation by wM and that you are restricted by the JMS API. Find out if you can specify the client name through the JMS API. If not then you could probably just use the java API to connect directly to the broker. This should work just fine if you are only publishing documents. You don’t even have to specify the client name as one is automatically created for each new connection.
The JMS API becomes useful when you need Message EJBs invoced based on the subscribed documents.
You’re right that I’m using the WM EJMS provider, and that I’m restricted by the JMS API. I’m bound to using this API as I also have a lot of clients (EJB’s (Messagedriven Beans and Session Beans) listening to the JMS queue.
I took a closer look at the API, and there was no way for me to specify the client-name (the API methods for doing so was protected, and by definition that means that the TopicConnectionFactory is responsible for doing so). I thought that this was strange behaviour for the API to not be able to support multiple publishers, and after doing a lot of research I found the error. I’ve installed the EJMS Service Pack 2 earlier to overcome some other issues, and that was my problem. JMS SP1 supports mulitple publishers, but a bug in SP2 prevents this from working (I’ve also tried the happycars example shipped with WM, and that didn’t work on SP2).
It looks like you’ve found a solution, so I’m not sure that this will be helpful or not. I ran into this problem a while ago and was able to resolve it by setting the sharedState attribute to true in the deployment descriptor. This attribute is set in the QueueConnection element and configures the clients created by the provider to have the shared state set to true. This can be verified in Enterprise Manager by looking at the client whose name matches the name of the queue. You may have to delete the client in Enterprise Manager before running your code with the shared state attribute as this only appears to be configured when the client is created.