[jcifs] deadlock/hanging

Michael B. Allen miallen at eskimo.com
Sat Jul 6 14:55:37 EST 2002

On Fri, 5 Jul 2002 15:55:43 -0500
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:

> I need to contact Tim and figure out why this message didn't make it to 
> the jCIFS list.  In the meantime, I am forwarding it to the list.

Well, mediagroks.com is not DNSBL listed.

> Chris -)-----
> ----- Forwarded message from Greg Pavlik <greg_pavlik at mediagroks.com> -----
> >
> > From: Greg Pavlik <greg_pavlik at mediagroks.com> 
> > Date: Fri Jul 05, 2002  03:52:36 PM US/Eastern 
> > To: jcifs at lists.samba.org 
> > Subject: deadlock/hanging 
> > 
> > 
> > I am experiencing some strange behavior with JCIFS. When I run the 
> > client, the client hangs, and while this is repeatable, it doesn't 
> > happen in all test cases. It always occurs when I run inside of a 
> > more complicated Java program, in this case an app server -- though I 
> > am executing tests serially. I am accessing a share that is on my 
> > test box (the box that is running the client), a Windows2000 HP 
> > laptop. 
> > 
> > What is even more unexpected is that all clients will hang even if 
> > the test runner is restarted. I can not get an SMB client to not hang 
> > when connecting to my share unless I reboot the entire machine. 
> > 
> > My code at this point is creating a new SmbFile using the constructor 
> > public SmbFile( SmbFile file) -- ie, it is presumably leveraging an 
> > existing connection to resolve to a new resource. 
> > 
> > The following is a stack trace from the blocking thread. Any tips 
> > would be greatly appreciated. Thanks. 
> > 
> > "executor-1" prio=5 tid=0xd7ef598 nid=0x6ac waiting on monitor 
> > [0x10b5f000..0x10b5fdbc] 
> >        at java.lang.Object.wait(Native Method) 
> >        - waiting on <2b9f700> (a java.lang.Object) 
> >        at java.lang.Object.wait(Object.java:420) 
> >        at 
> > jcifs.UniAddress.lookupServerOrWorkgroup(UniAddress.java:162) 

It's  dying  in  the  middle  of  the NetBIOS name service lookup. I recall
another  user having a problem with a Win2K laptop. I believe it turned out
that the laptop was turning off the server service (CIFS server) and unused
interfaces to conserve power.

This  is  very  hard for me to debug from this vantage point. You might try
flipping  on  debugging  with  the  -Dlog=ALL  flag to see what's happening
precisely at the point of failure. I suspect the client is sending a packet
out  to  which there is no reply. This takes several minutes to timeout but
that  may  be after your app server decides to kill the thread. You'll have
to  try  different  hardware  arrangements  to deduce what network/hardware
configuration  is  at fault. I don't think it's jCIFS itself because no one
has  reported  a  problem like this is some time (although it's possible of
course).  In  general, if your product is intended to contact the localhost
server  service on a laptop I don't know if that's feasable because there's
no  guarantee that the server service will be available to network clients.


More information about the jcifs mailing list