Message Publishing using pooled connection.

[ctimothy]

I have created the pooled publisher connections. However, I am always getting "Exception: javax.jms.IllegalStateException: The session is closed" when I try to publish a message. It happens when I call session.createObjectMessage(msg). Is there anyway to tell if the connection is Ok from the console? Or do I have to reset the connection everytime before I use it?

Thanks,

[ctimothy]

Yes we have. Here are snippets of our code:


tcf_ = (TopicConnectionFactory) context_.lookup(connectionFactory_);
conn_ = tcf_.createTopicConnection ();
conn_.setExceptionListener(new ExceptionListener() {
public void onException(JMSException e)
{
if (!restarting_)
JMSInterface.shutdownAndRestart(e);
}
});


In "shutdownAndRestart" we attempt to disconnect and reconnect to JMS. We log several messages - which I do not see in this case. Here are more snipets of the code:


private static void shutdownAndRestart(Throwable t) {

TSLogger.getMainLogger().debug("JMS Service Failure", t);
restarted_ = false;
synchronized (JMSInterface.class) {
if (restarted_)
return;
restarting_ = true;
for (;;) {
TSLogger.getMainLogger().warn("JMS service not reachable ... will try again in a few seconds");
try {
Thread.sleep (reconnectTimeout_);
}
catch (InterruptedException ie) {}

... etc


We don not see the warning message. In a more typical operation, when we shut down JBoss we see the warnings logged by the clients. When JBoss is restarted the clients reconnect and continue.

...richie

[ctimothy]

It seems JBoss it is closing the connection with some reason.


12/08 16:26:35.632[org.jboss.jms.asf.StdServerSessionPool$DefaultThreadFactory@a58086 Thread Pool Worker-0]INFO Closing a connection for you. Please close them yourself: org.jboss.resource.adapter.jms.JmsSession@107e577
java.lang.Exception: STACKTRACE
at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:319)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:477)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:838)
at org.jboss.resource.adapter.jms.JmsSessionFactoryImpl.allocateConnection(JmsSessionFactoryImpl.java:369)
at org.jboss.resource.adapter.jms.JmsSessionFactoryImpl.createTopicSession(JmsSessionFactoryImpl.java:159)

[darranl]

Where are you using the connection that you have established?

Are you obtaining the connection immediately prior to publishing the message or are you getting connections in advance in a component and then trying to use it later?

[ctimothy]

I am using the connection after updating the database table to refresh the internal cache. The connections are established at the server startup in advance in the pool. However, it seems JBoss decided to close them after I created them.

Thanks,

[ctimothy]

I have figured out what is going on. The connection pool is maintained within the singleton object. When the singleton was initialized within the scope of the bean's public method, everything was ok until the function returnes to the caller. JBoss knows the connections are created within the activation of the bean and exited without closing the connection, then it decides to close the open connections automatically. How can I disable this feature?

Thanks.

[adrian.brock]

Why would you want to?

What you are doing is wrong. Pooled connections should not be allocated to singletons.
They don't understand transaction/thread/ejb invocation context.

You certainly shouldn't keep a Pooled connection open indefinitely, otherwise
there is little point pooling it.

And there is certainly no need to install an ExceptionListener on a pooled jms connection.
The JMS resource adapter should be handling the failures.

Use of threading primitives is also bad in an application server. Read the spec.

[ctimothy]

The ExceptionListener part is not mine :) Anyway, the reason to have opened connections ready, is to publish the message as fast as I can. If it takes too long to create a session to send the message, it is not practical in business reason.

Thanks.