[jcifs] Note about jcifs.smb.client.(responseTimeout|soTimeout)

[Ronny Schuetz]

Hi Michael,

just ran into an racing condition issue with jCIFS 1.2.7 (however, the 
code seems to be unchanged in the latest version, but we're planning to 
upgrade to use DFS), where threads started by

jcifs.util.transport.Transport.doConnect()

are piling up and causing OutOfMemory errors at a certain point in time 
where no native threads can be started anymore (at least on HP-UX).

=== Setup ==============================

A test client retries more or less immediately (there is just a short 
delay) to open a connection to a non-reachable server resp. server that 
responds very slowly in SmbTransport#negotiate() as soon as the previous 
attempt failed.

jcifs.smb.client.responseTimeout was set to 60000, 
jcifs.smb.client.soTimeout was set to 90000.

=== Issue ==============================

The values for the timeouts are listed above. The documentation 
recommends 30000 and 35000, the defaults are 10000 and 15000 so the 
issue will appear here as well, but it will take longer.

As the socket timeout is higher than the response timeout, the threads 
started in SmbTransport#doConnect() do not finish before the wait() in 
Transport#connect() times out in case the server does not respond in 
SmbTransport#negotiate().

Due to the synchronized block in SmbTransport#negotiate(), threads for 
the same destination are queued up.

As the client is more or less retrying immediately trying to open a 
connection after a failed connection attempt, more and more threads are 
started, so at some point in time, the thread start in 
Transport#connect() fails with an out of memory error ("unable to create 
new native thread" on HP-UX) leaving the transport in an invalid state 
(== 1) and might cause other classes to fail to start threads as well.

=== Proposed solution ==================

It would be better IMHO to use a much higher value for responseTimeout 
than for soTimeout, maybe the following should be true:

  responseTimeout >= 2 * soTimeout

(*2 due to potentially multiple negotiate() calls in 
SmbTransport#doConnect())

Btw, something else about jcifs.smb.SmbTransport: Maybe it would be good 
to use Socket#bind() and Socket#connect() instead of the used Socket 
constructor to set a timeout already for the connection phase to avoid 
waiting forever in such cases.

However, the library runs pretty stable for us although we're shuffling 
a lot of files around the world every day. Keep up the good work, thanks 
a lot!

Best regards,
Ronny