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

Michael B Allen miallen at ioplex.com
Tue Apr 8 18:58:38 GMT 2008

I'll add this to the TODO for further investigation.


On Tue, 08 Apr 2008 20:38:04 +0200
Ronny Schuetz <Usenet.r96 at gishpuppy.com> wrote:

> 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

Michael B Allen
PHP Active Directory SPNEGO SSO

More information about the jcifs mailing list