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

Remi Lefevre wrote:
> 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
>   
The 0.7.6 branch has a few connection management issues that cannot 
easily be resolved. Work on this
was abandoned in favour of the new approach in 0.7.7.

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