[jcifs] accumulation of sockets in CLOSE_WAIT state: update

[Gary Rambo]

In addition to the NBSS Negative Session Response, "Called name not present", another way to generate an accumulation of sockets in CLOSE_WAIT state is NBSS Negative Session Response, "Called name present but insufficient resources" (NbtException.NO_RESOURCES). 

I've got a server on its last legs. It has enough juice to accept a TCP connection but it responds to the NBSS session request with Negative Session Response: Called name present but insufficient resources. I don't know how to capture this in a sample program.

The SmbTransport.java ensureOpen() do-while loop gets a new NbtSocket; the constructor calls the NbtSocket.connect() method; if the connect() fails for any of several reasons including Negative Session Response, it throws an IOException which returns to ensureOpen() as an NbtException. The underlying TCP socket remains open and we remain in the loop, getting another new NbtSocket. The Negative Session Response case in NbtSocket.connect() -- and probably the other failure cases as well -- should invoke the close() method before throwing the exception.

Thanks.

Gary

Gary Rambo wrote:
> I haven't yet come up with a sample program that accumulates CLOSE_WAIT
> sockets, and I haven't had time to walk down the differences between a
> sample program and my code. Part of the difficulty is that it typically
> take a number of weeks to accumulate a dangerous number of CLOSE_WAITs.
> 
> For a while I thought moving to 0.8.1 solved it but it didn't.
> 
> I'm continuing to work on it.
> 
> Thanks.
> 
> Gary
> 
> Michael B Allen wrote:
> 
>>Gary Rambo said:
>>
>>
>>>Greetings!
>>>
>>>I'm accumulating sockets in CLOSE_WAIT state that result from the
>>>SmbTransport.ensureOpen() method: before entering the do{}while() loop
>>
>>the
>>
>>
>>>address.firstCalledName() returns something like SPUD<20>; in the loop
>>
>>I
>>
>>
>>>get a new NbtSocket with the calledName; the NBSS session request
>>>invariably fails with a "Called name not present" response, and I
>>
>>cycle
>>
>>
>>>through the loop with address.nextCalledName(), get a new NbtSocket
>>>returning *SMBSERVER<20>, which invariably works. However the first
>>>NbtSocket is left hanging, and netstat shows a buildup of these
>>>netbios-ssn sockets in CLOSE_WAIT state. Eventually I hit the
>>
>>per-process
>>
>>
>>>file descriptor limit and I begin seeing "Too many open files"
>>
>>messages as
>>
>>
>>>I try to move about.
>>>
>>>Closing the failed socket appears to close the good socket as well. My
>>>workaround is to ignore the firstCalledName() and begin the loop with
>>
>>the
>>
>>
>>>nextCalledName(). Should firstCalledName() work for the NBSS session
>>>request? What's the downside of ignoring it?
>>
>>
>>I don't understand this. What are you doing exactly? Are you trying to
>>"scan" the network or is this just general purpose usage? Can you
> 
> write
> 
>>a
>>trivial program to reproduce this phenomonon? I might be able to do a
>>little cleanup but I don't understand why jCIFS would try to open so
>>many
>>file descriptors. You would have to open hundreds before reaching the
>>limit.
>>
>>Mike
>>
>>
>>
>>
>>>Thanks.
>>>
>>>Gary Rambo
>>>
>>>
>>
>>
>