RE: Hung threads accessing domain controller

Hi Mike,

We recently put in the change that you made in order to attempt to
resolve the hanging thread problem (jcifs 1.1.7), but it did not fix our
issue.  We are still getting threads hanging on the Object.wait() on
line 877 of SmbTransport.java of the negotiate() method.  It appears
that the thread hangs after receiving a "timeout waiting for response
from server" exception in the SmbTransport.send() method (line 677).  We
are hoping you would have some more insight into what the issue might
be.  Thanks for any help you can offer.

Thanks,
Scott Christensen


-----Original Message-----
From: Michael B Allen [mailto:mba2000@xxxxxxxxxx] 
Sent: Thursday, January 13, 2005 1:37 PM
To: Christensen, Scott M
Cc: jcifs@xxxxxxxxxxxxxxx
Subject: Re: [jcifs] Hung threads accessing domain controller

On Thu, 13 Jan 2005 10:37:29 -0600
"Christensen, Scott M" <SCHRIST1@xxxxxxxxx> wrote:

> > What evidence do you have to suggest that these threads are never
> released?
> 
> Websphere has a thread monitor that analyzes the current threads and
> responds if threads appear to be in a hung state.  We are seeing the
> number of hung threads increase over a period of days to the point
where
> every thread is in a hung state.  Here is the message that is reported
> 
> [1/13/05 8:46:05:009 CST]  10f405e ThreadMonitor W WSVR0605W: Thread
> "Servlet.Engine.Transports : 27795" (83978c) has been active for
760,739
> milliseconds and may be hung.  There are 32 threads in total in the
> server that may be hung.
> 
> This number increases sequentially and never goes down.  Every one of
> the threads is hanging on an Object.wait() call
(SmbTransport.java:877).

This is indeed hanging threads. When multiple threads try to call into
the jCIFS library only one is allowed to perform the negotiation with
the DC. The others are asked to wait at SmbTransport.java:877 but never
notified when the negotiation is complete (so they can simply return).

I believe the fix is to add a notify:

    947         state = ST_NEGOTIATED;
    948         notify();
    949     }

I'll have to look at this closer and test it out a little.

> Line 877 in SmbTransport.java is a call to a never ending wait().  I
am
> assuming that there is another thread that will notify the thread that
> this wait() corresponds to, but I am unable to find where that call
may
> happen.  And if it happens to be associated with the
> jcifs.smb.client.responseTimeout, it appears that this timeout is not
> happening.

You are correct and there is no notify(). Nice catch Scott.

Mike

-- 
Greedo shoots first? Not in my Star Wars.