Urgent!!!: Usage of connectionfactory with pre-configured client-id gives invalidclientidexecption
Raymond Brandon
Hi All,
I'm deploying a message driven bean on WL7 that, in it's deployment descriptor
does NOT set the client id, but uses the connection-factory-jndi-name to refer
to a connectionfactory that has been configured for durable subscriptions. In
this configuration, I filled in the client id field.
When I deploy my mdb, I keep getting the exception below, saying that the client
id is already in use. I don't understand this!
TIA,
Raymond
<Apr 23, 2003 11:07:03 AM CEST> <Warning> <EJB> <010096> <The Message-Driven EJB:
EJBMDBComponent is unable to connect to the
JMS destination: topic/MyTopic. Connection failed after 2 attempts. The MDB will
attempt to reconnect every 10 seconds, this
log message will repeat every 600 seconds until the condition clears.>
<Apr 23, 2003 11:07:03 AM CEST> <Warning> <EJB> <010061> <The Message-Driven EJB:
EJBMDBComponent is unable to connect to the
JMS destination: topic/MyTopic. The EJB container will automatically attempt
to re-establish the connection with the JMS ser
ver. This warning may occur during WebLogic Cluster start-up if the JMS destination
is located on another server. When the JM
S server connection is re-established, the Message-Driven EJB will again receive
JMS messages.
The Error was:
The Message-Driven EJB failed while creating a JMS Connection. The error was:
weblogic.jms.common.InvalidClientIDException: Client id, PTCF1, is in use
weblogic.jms.common.InvalidClientIDException: Client id, PTCF1, is in use
at weblogic.jms.frontend.FEConnection.setClientId(FEConnection.java:1163)
at weblogic.jms.frontend.FEConnection.<init>(FEConnection.java:210)
at weblogic.jms.frontend.FEConnectionFactory$1.run(FEConnectionFactory.java:391)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:785)
at weblogic.jms.frontend.FEConnectionFactory.connectionCreate(FEConnectionFactory.java:388)
at weblogic.jms.client.JMSConnectionFactory.createConnection(JMSConnectionFactory.java:122)
at weblogic.jms.client.JMSConnectionFactory.createTopicConnection(JMSConnectionFactory.java:80)
at weblogic.ejb20.internal.JMSConnectionPoller.getConnection(JMSConnectionPoller.java:566)
at weblogic.ejb20.internal.JMSConnectionPoller.createJMSConnection(JMSConnectionPoller.java:1643)
at weblogic.ejb20.internal.JMSConnectionPoller.connectToJMS(JMSConnectionPoller.java:991)
at weblogic.ejb20.internal.JMSConnectionPoller.trigger(JMSConnectionPoller.java:881)
at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.java:181)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:744)
at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:167)
at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:161)
at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:38)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)
>
Bart Simpson
Hi,
How are you doing? Setting the client id at the factory level is practically
useless. From the stack trace it looks like someone has already obtained the
connection from the connection factory using the client id. So, when another
XXX obtains a connection using the same client id you will see the exception below.
I would highly recommend that you do not set the client id in the connection
factory...
Best regards,
-Bart
Raymond Brandon
Hi Bart,
If this is true what you say, then why do the connnection factories have this
property? In addition, the JMS spec says that the preferred way to obtain a durable
subscription is to use a separate connection factory for each of the subscribers,
so I would think that these connection factories would then have the client id
set instead of doing this in the MDB.
Also, what happens if I use topic connection factory X which does not have it's
client id field set and multiple mdb's use this connection factory to subscribe
durably to their own topics by setting their own client id in their deployment
desriptors, would this give a conflict or is it safe to do it this way?
TIA,
Raymond
Tom Barnes
Raymond Brandon wrote:
> Hi Bart,
>
> If this is true what you say, then why do the connnection factories have this
> property? In addition, the JMS spec says that the preferred way to obtain a durable
> subscription is to use a separate connection factory for each of the subscribers,
> so I would think that these connection factories would then have the client id
> set instead of doing this in the MDB.
The specification mentions it for "exactly-once" enforcement. eg, It
prevents two versions of the same app from booting at the same
time. But real life has quickly determined that enforcing this
at the CF level, or even the connection level,
is not really useful, and is more painful than helpful to
JMS user and JMS vendor alike. It would have been better just
to do it at the server/topic level. I don't have time to go into
details. Trust me, it is not pretty.
>
> Also, what happens if I use topic connection factory X which does not have it's
> client id field set and multiple mdb's use this connection factory to subscribe
> durably to their own topics by setting their own client id in their deployment
> desriptors, would this give a conflict or is it safe to do it this way?
As long as each descriptor has a different client-id value, there
is no conflict.
Actually, the CF connection-id *is* useful but only
as a work-around dealing with those that want multiple MDB pools
with the same name and deployment descriptor to each have
their own subscription. See attached.
Tom, BEA