[jcifs] Reconnect

[Allen, Michael B (RSCH)]

Daniel,

As I mentioned in out offline conversation, it was not clear to me that you
were  restarting  the  server. Normally jCIFS closes a transport after some
configurable amount of time (15 sec by default) to conserve resources. What
was  meant  by  "gracefull  reconnect"  was  that  these  transports  would
automatically be re-established to serivce new requests.

At  first  I  thought that I might be able to make jCIFS more robust in the
event  the  server  socket closes however it's not clear to me how I should
handle  such  a  situation.  Java  does not detect if the server socket has
closed.  You  would  have to try and read or write to detect this condition
and  then  reissue the request. However there is state in the session and I
don't  think  it is reasonable to introduce the additional complications of
trying  to second guess the transport layer like that. How could jCIFS know
that  the user didn't want the client to generate an exception if it cannot
contact the server? 

There  is  some  consolation. When this condition occurs an SmbException is
thrown  however this reinitializes the state of the transport, session, and
tree  which  means  simply  trying  to  perform the operation again will be 
successfull.  So  If I catch that SmbException and simply try to read again
like this modified SlowRead.java: 

        int n, tot = 0;
        while( true ) {
    try {   
          if(( n = in.read( b )) <= 0 ) {
            break;  
          }       
          System.out.write( b, 0, n ); 
          tot += n;
          Thread.sleep( 17000 );
    } catch( IOException ioe ) { 
      ioe.printStackTrace();
    }
        }       

I get the exception if I restart the server but it tries and succeeds right
after: 

    [miallen at miallen1 jcifs]$ java SlowRead smb://miallen:pass@miallen1/tmp/cookies
    # Netscapejcifs.smb.SmbException: Timeout waiting for response from server. MIALLEN1<20>/127.43.43.56
            at jcifs.smb.SmbTransport.send(SmbTransport.java:483)
            at jcifs.smb.SmbSession.send(SmbSession.java:135)
            at jcifs.smb.SmbTree.send(SmbTree.java:91)
            at jcifs.smb.SmbFile.send(SmbFile.java:499)
            at jcifs.smb.SmbFileInputStream.read(SmbFileInputStream.java:139)
            at jcifs.smb.SmbFileInputStream.read(SmbFileInputStream.java:103)
            at SlowRead.main(SlowRead.java:34)
     HTTP Cook

Notice  that  the  read  continued from where it left off. This is really a
totally  new  session  and  the  file has a new FID but the offset is still
accepted.

> -----Original Message-----
> From:	Daniel Cox [SMTP:dcox at microbits.com.au]
> Sent:	Thursday, September 26, 2002 11:35 AM
> To:	jcifs at lists.samba.org
> Subject:	[jcifs] Reconnect
> 
> The CHANGES file suggests that reconnect should work nicely.
> 
> I have a small test class :-
> - it constructs an SmbFile and calls listFiles()
> - then pauses 10seconds
>  (this gives me time to find the process id on a samba server and kill
>  the connection)
> - then constructs a new SmbFile and calls listFiles() again
> 
> But the second call throws the following exception :-
> 
> Exception in thread "main" jcifs.smb.SmbException: Timeout waiting for 
> response
> from server. TEST<20>/192.168.100.200
>         at jcifs.smb.SmbTransport.sendTransaction(SmbTransport.java:615)
>         at jcifs.smb.SmbSession.sendTransaction(SmbSession.java:85)
> ..
> 
> I have tried this with 0.6.5 and 0.7.0b3.
> 
> Are there properties that need to be set for this to work correctly
> Or is there any other way to reset the connection information when
> exception is caught?
> 
> Thanks for any help you may be able to provide.
> Daniel.