Re: EJUKEBOX and Java

[Brian Tinsley <btinsley@emageon.com>]

Thanks, but that's not the case. The IBM JVM uses native threads as it 
should. We have recently discovered, however, that they apparently have 
signal handling problems that are leading to this deadlock. Our 
developers were able to write a small app that consistently reproduces 
the deadlock on both their 1.3.0 and 1.3.1 releases. We have not been 
able to reproduce the problem with Sun's JVM, thus the finger points to 
to the IBM JVM.


Lever, Charles wrote:

>this could appear because your Java threads are emulated
>entirely in user space (green threads?).  if one of the
>threads goes into the kernel via a system call and doesn't
>return, then your entire JVM is hung.
>
>just a thought.
>
>>-----Original Message-----
>>From: Brian Tinsley [mailto:btinsley@emageon.com]
>>Sent: Tuesday, April 02, 2002 7:39 PM
>>To: Kent, Ian I.
>>Cc: nfs@lists.sourceforge.net
>>Subject: Re: [NFS] EJUKEBOX and Java
>>
>>
>>Understood, but when the EJUKEBOX error is encountered by our 
>>application, the fact that RPC blocks signals (via rpc_clnt_sigmask) 
>>during this sleep seems to cause every thread in the Java VM to 
>>"deadlock" (we can even see the garbage collector stop) until data 
>>starts to stream back from the NFS server. This is our 
>>current working 
>>theory anyway.
>>
>>
>>Kent, Ian I. wrote:
>>
>>>The NFSv3 RFC specifies the client behaviour you are seeing 
>>>
>>for this server return.
>>
>>>It's not a deadlock, the client sleeps, then retries.
>>>
>>
>>
>>_______________________________________________
>>NFS maillist  -  NFS@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/nfs
>>

-- 
Brian Tinsley
Senior Systems Engineer
Emageon





_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs