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

Rajeshwar Neelam neelam.rajeshwar at alcoa.com
Wed Apr 9 07:07:08 GMT 2008


Hi Ronny/Michael,
                        Cam you help me rgarding this error.

                    we have domain contoller in US and we have two doamins
i.e US and Austrlia.We implemented the this jcifs for our application and
this application using US as well as Austrlian users. 
                   We are using Oracle Application server 10.1.3 and jcifs
1.2.13 API . We are getting bellow error regularly for Austrlian users when
they try to connect to that application. And after some time i.e after 10
mintus  or 20 minuts if you connect then we can connecting to that
application. 
                  We set up the soTimeOut is 60000 and reponseTiemOut is
60000. Can you tell the what are maximum limits for these timings and to
solve bellow problem do i need to change the times are enough ? or do i need
to update the jar? ????


           Please give the solution as soon as possible for following
error...... 


500 Internal Server Error 

jcifs.smb.SmbException: 
jcifs.util.transport.TransportException 
java.net.SocketTimeoutException: Read timed out 
at java.net.SocketInputStream.socketRead0(Native Method) 
at java.net.SocketInputStream.read(SocketInputStream.java:129) 
at jcifs.util.transport.Transport.readn(Transport.java:29) 
at jcifs.smb.SmbTransport.peekKey(SmbTransport.java:355) 
at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:268) 
at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:299) 
at jcifs.util.transport.Transport.run(Transport.java:240) 
at java.lang.Thread.run(Thread.java:534) 
at jcifs.util.transport.Transport.run(Transport.java:256) 
at java.lang.Thread.run(Thread.java:534) 
at jcifs.smb.SmbTransport.connect(SmbTransport.java:289) 
at jcifs.smb.SmbSession.getChallenge(SmbSession.java:146) 
at jcifs.smb.SmbSession.getChallenge(SmbSession.java:140) 
at jcifs.http.NtlmHttpFilter.negotiate(NtlmHttpFilter.java:157) 
at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:114) 
at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0 
at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0 
at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0 
at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0 
at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0 
at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0 
at java.lang.Thread.run(Thread.java:534)                 
          

Ronny Schuetz-4 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
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Note-about-jcifs.smb.client.%28responseTimeout%7CsoTimeout%29-tp16570347p16580846.html
Sent from the Samba - jcifs mailing list archive at Nabble.com.



More information about the jcifs mailing list