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

Ok, I confirm my bug is fixed by this modification in HEAD.
I'm able to reproduce it when compiling exolabcore from the 0_3_7 tag.

Any reason not to have released an official version of exolabcore with
this fix included ?

Thank you.

R. Lefevre

On 5/1/07, Remi Lefevre <[email protected]> wrote:
> 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/