[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
> 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
> 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
> 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,
Michael B Allen
PHP Active Directory SPNEGO SSO
More information about the jcifs