JMS dealock sending object message

[Derekjb]

Hello,
I am getting an deadlock sending a persistent ObjectMessage from
inside a bean manages transaction session bean. The message is sent
without an transaction. My store is an Oracle 8 server and my WLS is
version 6.1 sp2. Java version jdk 1.3.1 and Os is SOLARIS 8. Am I
running into a blob writing issue or do I need to change something in
the way I am setting up my server. Please note that this does not
happen that often (but once is too many times). The error that occurs
when the send finally times out is (the thread dump for the Blocked
thread is included after this error):

"Suspend Checker Thread" prio=10 tid=0xaa178 nid=0x9 runnable
<Oct 11, 2002 1:24:19 PM EDT> <Alert> <JMS> <JMSServer "COServer", store
failure while writing message for topic COJMSTopic, java.io.IOException:
JMS JDBC store, connection pool = <COPool>, prefix = <null>: write failed
java.sql.SQLException: Io exception: Connection timed out: Connection
timed out
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:210)
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:323)
at
oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1460)
at
oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371)
at
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900)
at
oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:293)
at weblogic.jms.store.JDBCIOStream.write(JDBCIOStream.java:344)
at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:250)
at weblogic.jms.store.JMSStore.execute(JMSStore.java:182)

While the EJB is blocked, the thread dump for the blocked thread looks like:

"ExecuteThread: '95' for queue: 'default'" daemon prio=5 tid=0x453cb0
nid=0x6c waiting on monitor [0xe8a7f000..0xe8a819e0]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:420)
at
weblogic.jms.dispatcher.Request.sleepTillNotified(Request.java:198)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:606)
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:149)
at weblogic.jms.dispatcher.Request.dispatchAsync(Request.java:734)
at weblogic.jms.frontend.FEProducer.send(FEProducer.java:240)
at weblogic.jms.frontend.FEProducer.invoke(FEProducer.java:291)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510)
at
weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:332)
at
weblogic.jms.client.JMSProducer.sendMessage(JMSProducer.java:269)
at weblogic.jms.client.JMSProducer.publish(JMSProducer.java:114)
at
com.concentra.claimops.communication.eventpublisherejb.EventPublisherEJB.publishMessage(EventPublisherEJB.java:148)
....cut for brevity......

[Tom Barnes]

Hi,

This doesn't appear to be a dead-lock so much as database timeout. Is
the database connection idle for a long while before this call?
Is it possible your network between the database and JMS is unreliable?

Tom

[Derek Jean-Baptiste]

Tom,
The DB pool is inactive for a while and the network is highly
reliable. Is there
any thing I can do to ensure the pool connection used by the JMS publish
has not gone stale?
Also, I have seen that there are some bugs related to blobs and WLS 6.1
sp2 fixed by sp3
could these be effecting my object messages being saved to the DB?
Thanks
Derek

[Tom Barnes]

I think the JDBC connection is going stale. There has been code added to try and renew
the connection, but I'm not sure which service pack. Contact customer support to find out.

The only why to keep the connection alive otherwise is to either:
A) tune the database or perhaps the driver to increase the timeout
for idle connections (not sure how, database specific)

B) force JMS to hit the database periodically, either via sending then
removing a persistent message on an unused destination
or by configuring an unused topic, and then creating or
removing a durable subscription...

Tom, BEA

[Derekjb]

decreasing the time between DBPool tests solved this problem.
I additionally have WLS check the pool connection before letting it be
reserved for use.
Thanks for your help
Derek