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

See inline.

Remi Lefevre wrote:
> 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 ?
>   
No. CVS head has unreleased changes. The exolabcore-0.3.7.jar comes from 
the exolabcore_0_3_7
tag.

> - 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) ?
>   
JDK 1.2
> - 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 ?
>   
No. It shouldn't make any difference.
>
> 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/