Client hangs in receiveNoWait() (exolabcore-0.3.7.jar byte code bug ?)

Hi,

I use openjms 0.7.6.1 and the exolabcore-0.3.7.jar included in the
release package.

When I restart my openjms server (unavailable for a few seconds), the
client which periodically checks for new messages sometimes hangs
indefinitely on the receiveNoWait() call  instead of properly losing
the connection as this happens most of the time.

When this happens, the client connections are stucked in CLOSE_WAIT state:

tcp        1      0 10.0.0.1:47113       10.0.0.2:3035
CLOSE_WAIT  26670/java
tcp        1      0 10.0.0.1:46371       10.0.0.2:3035
CLOSE_WAIT  12377/java
tcp        1      0 10.0.0.1:46182       10.0.0.2:3035
CLOSE_WAIT  12377/java
tcp        1      0 10.0.0.1:46297       10.0.0.2:3035
CLOSE_WAIT  12377/java
tcp        1      0 10.0.0.1:46240       10.0.0.2:3035
CLOSE_WAIT  12377/java
tcp        1      0 10.0.0.1:47005       10.0.0.2:3035
CLOSE_WAIT  26670/java

Here is the thread dump of the blocked thread doing the receiveNoWait
call (it is always exactly the same one):

Apr 16 12:14:57 client wrapper[info] 100  jvm 1 "TimerThread -
Thread[Thread-22,6,main]" prio=7 tid=0x02f859f8 nid=0x694 in
Object.wait() [b3ff000..b3ffd94]
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
java.lang.Object.wait(Native Method)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
java.lang.Object.wait(Unknown Source)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.core.mipc.Queue.remove(Queue.java:93)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 - locked <0x12f619a0>
(a java.util.LinkedList)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.core.mipc.QueueInputStream.receive(QueueInputStream.java:93)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.core.mipc.ObjectChannel.receive(ObjectChannel.java:141)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.jms.client.mipc.IpcJmsSessionStub.checkReply(IpcJmsSessionStub.java:841)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.jms.client.mipc.IpcJmsSessionStub.receiveMessage(IpcJmsSessionStub.java:243)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 - locked <0x12f619d8>
(a org.exolab.core.mipc.ObjectChannel)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.jms.client.JmsSession.retrieveMessage(JmsSession.java:728)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 - locked <0x12f62db0>
(a java.lang.Object)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.jms.client.JmsMessageConsumer.retrieveMessage(JmsMessageConsumer.java:322)
Apr 16 12:14:57 client wrapper[info] 100  jvm 1 at
org.exolab.jms.client.JmsMessageConsumer.receiveNoWait(JmsMessageConsumer.java:230)


Now here is the suprising thing:

Because I wanted to insert some debug code in exolabcore classes, I
checked it out from CVS and compiled it with java 1.4.2.
Before doing any modification, I tested that the jar was working
correctly and, surprisingly, the bug had disappeared (I was previously
able to reproduce it very easily with the release version). This
raises a few questions:

- Is the CVS source code of exolabcore (HEAD) exactly the same as the
one used to release exolabcore-0.3.7.jar ?
- Is there any way to know which version of java (javac) had been used
to compile the release version of exolabcore-0.3.7 (and
openjms-0.7.6.1) ?
- Is it possible that the problem comes from the byte code of
exolabcore-0.3.7 release version (decompiling this version and my own
compiled one raised quite a lot of differences) ?
- If so, should I recompile the whole openjms-0.7.6.1 code to prevent
others issues ?


Sorry for all these questions, but I'm puzzled by this issue.

Best regards,

R. Lefevre

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/