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

Thanks for drawing attention to the differences between exolabcore
0.3.7 and HEAD. I had no access to "cvs diff" at this time.

I now see that there has been a single modification in
"core/mipc/Demultiplexer.java" to make register and unregister methods
synchronized. I will check tomorrow if this explains my bug vanishing.

On 5/1/07, Tim Anderson <[email protected]> wrote:
> 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/
> _______________________________________________
> openjms-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openjms-user
>

-------------------------------------------------------------------------
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/