Client Id in use - WL6.1 sp3 server to server JMS messaging

[Alan May]

Any feedback would be greatly appreciated. THANKS!

-Alan May

Scenario:

Two weblogic 6.1 sp3 instances running on two separate Solaris 8 boxes.

Server a - a message producer(client) for a number of topics and queues on b

Server b - hosts JMS services including all the topics and queues, has both
message producers and mdb consumers for a number of topics and queues

What I've set up: a durable connection factory for topics for server a,
topics for server b, queues for server a, and queues for server b (all
targeted to server b)

I have a singleton on each server that has methods to retrieve the queue
connection or topic connection appropriate for that server(a single
connection is
shared for all topic producers and a separate connection is share for all
queue producers for each server)

I have each producer open and close a new session every time. However, the
topic and queue connections are shared for all producers for that JVM. This
seemed to be the approach recommended by the JMS spec, but do you feel this
is the appropriate granularity given the above scenario? I am not currently
closing my jms connection as part of a weblogic shutdown class. Is that
essential in that case? If the server crashes - are there any
recommendations on how to handle(if closing the connection is the issue)?

I've confirmed that my JMS clients running with server b are not using the
connection factories setup for a's use.

Issue:
------
Everything works on server b as expected.

Server a's connections seemed to be fouled. I was getting that the clientid
was in use(stack trace included below) while trying to fetch the connection.

I stopped server a, removed the fouled connection factories on server
b(dedicated for server a's use), and created new connection factories for
a's use. I stopped server b and deleted everything from the two JMSState
and JMSStore tables, restarted a then b, and tried the test again. This
time the singleton code could fetch the connection without receiving a
JMSException, but I was getting an exception when I tried to open a session
from the connection.

If worst comes to worse, I can stick a stateless session bean on b, to act
as a delegate producer on behalf of server a, but I'd like to avoid it if
possible.

Any recommendations? Please let me know if it would be helpful for me to
clarify any points.

Server a's original error:
weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
is in use

Start server side stack trace:
weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
is in use
at
weblogic.jms.frontend.FEConnection.setClientId(FEConnection.java:918)
at weblogic.jms.frontend.FEConnection.<init>(FEConnection.java:178)
at
weblogic.jms.frontend.FEConnectionFactory$1.run(FEConnectionFactory.java:319
)
at weblogic.management.internal.Helper.doLocally(Helper.java:1656)
at
weblogic.jms.frontend.FEConnectionFactory.connectionCreate(FEConnectionFacto
ry.java:316)
at weblogic.jms.frontend.FEConnectionFactory_WLSkel.invoke(Unknown
Source)
at
weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
at
weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
:93)
at
weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
at
weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
2)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
End server side stack trace

[Tom Barnes]

Hi Alan,

Lots of questions in one message! I'm going to
try and answer them using the shotgun approach -- let
me know if I miss.

(1) It is good practice to close JMS resources when you are done
with them, even if the destination host server crashes. The reason
is that the connection resource may be hosted on a different
WL server than the destination.

(2) Creating a session/producer per message is heavy-weight
in terms of CPU and network - if your app is performance
sensitive is is better to cache these resources for re-use.
See the JMS Performance Guide for details.

(3) From your description I can't tell which two
clients are conflicting. If what I'm writing here
doesn't help, please try to narrow it down and repost.

(4) Make sure that the connection factory does not have
a "client-id" configured for it. Otherwise only one client
can use the connection factory - instead have individual
clients dynamically set their ids.

(5) Note that client-ids are usually only useful for
durable subscriber access, as other types of clients
generally don't need exclusive connections, and therefore
don't need client-ids.

(6) The attached notes, which are for MDBs, may help you
understand durable subscriptions and client-id's better in general.

Tom