[jcifs] Hung threads accessing domain controller

[Christensen, Scott M]

> Ok, but I can see you're *not* using the provided NtlmHttpFilter.

In order to emulate container managed security using jcifs for NTLM
authentication and CA-Top Secret for authorization, we are using the
SecurityFilter (http://securityfilter.sourceforge.net) component.  The
code from the jcifs NtlmHttpFilter was copied into our own filter, but
it is the same code that is in NtlmHttpFilter. 



> This looks normal to me. Basically the domain controller accepted the
> connection but never responds to the negotiate request. This should
> timeout after jcifs.smb.client.requestTimeout.

I'm assuming you mean jcifs.smb.client.responseTimeout correct?  I was
unable to find a reference to jcifs.smb.client.requestTimeout in the
jcifs 1.1.6 code.



> 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).
Since we have not changed the timeout value for
jcifs.smb.client.responseTimeout, the default is still 10 seconds.
However, the thread in this example has been hung for over 10 minutes.
Also, as I said earlier, the number of hung threads never decreases and
continues for a number of days until all of the available threads are
hung and the JVM needs to be restarted.

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.

Thanks for all your hard work and for your time in looking into this.

Thanks,
Scott Christensen