[jcifs] Re: SmbException in jcifs-1.2.7

[Michael B Allen]

On Mon, 16 Jan 2006 10:30:08 +0000 (UTC)
Rainer Buss <rainer.buss at rbconsult.de> wrote:

> Michael B Allen <mba2000 <at> ioplex.com> writes:
> > ..
> > JCIFS is specifically designed for "concurrent access". But if
> > your network is flakey, increase your loglevel to 2 (should be ok in
> > production) and see if you're getting any timeouts. If so you might want
> > to look into the responseTimeout property.
> > ..
> 
> Hi Mike,
> 
> we followed your advice, increased the jcifs- loglevel and traced our 
> application. Several days there where some exceptions, but jcifs did not hang.
> This night jcifs had a severe problem, that caused loosing the connection
> to remote share permanently. Could you pls have a look at this.
> 
> We traced the following:
> 
> java.lang.StringIndexOutOfBoundsException: String index out of range: 2097248
	at java.lang.String.checkBounds
    ...
	at jcifs.util.transport.Transport.loop(Transport.java:108)
	at jcifs.util.transport.Transport.run(Transport.java:242)
	at java.lang.Thread.run(Thread.java:536)

The problem appears to be a corrupted response. The cause could be a
problem with the network or more likely the server had a hiccup and
chopped off part of a response.

In jcifs/util/transport/Transport.java line 113 change "IOException" to
"Exception" like the following:

   95   private void loop() {
   96     while( thread == Thread.currentThread() ) {
   97       try {
   98         Request key = peekKey();
   99         if (key == null)
  100           throw new IOException( "end of stream" );
  101         synchronized (response_map) {
  102           Response response = (Response)response_map.get( key );
  103           if (response == null) {
  104             if (log.level > 2)
  105               log.println( "Invalid key, skipping message" );
  106             doSkip();
  107           } else {
  108             doRecv( response );
  109             response.isReceived = true;
  110             response_map.notifyAll();
  111           }
  112         }
  113       } catch( Exception ex ) { <----- changed from IOException
  114         String msg = ex.getMessage();
  115         boolean hard = true;
  116
  117         if (log.level > 2)
  118           ex.printStackTrace( log );

Then rebuilt the jcifs jar file with 'ant jar'. See the end of the
README.txt file for detailed build instructions. Now install that jar and
you should be ok. No need to QA this. It's a fully backward compatible
change and very benign (and you don't have any choice :-).

This will prevent the JCIFS transport loop from exiting when a
RuntimeException like the one you're reporting occurs. It won't prevent
the error from occuring but it should allow the client to disconnect
cleanly thereby letting it reconnect to the server when it's behaving
better.

I will apply this to the next release of JCIFS.

> Afterwards we traced only exceptions like the following one for about
> 20 minutes and then no more entries have been written since reboot of
> our application.
> 
> [SUMMIT_INSTRUMENT-#1] transfer.FrontOfficeFileTransfer (?) - Error 
> transferring File : jcifs.smb.SmbException: 
> INFO   | jvm 1    | 2006/01/16 03:47:07 | 
> jcifs.util.transport.TransportException: Transport1[duss0485/15.1.15.151:445] 
> timedout waiting for response to Trans2QueryPathInformation

Typical response timeouts. Probably network slowness. Doubling the
response timeout might alieviate these a bit.

Mike