[jcifs] Re: SmbException in jcifs-1.2.7

[Michael B Allen]

Applied in 1.2.8 to be released RSN.

On Mon, 16 Jan 2006 13:51:10 -0500
Michael B Allen <mba2000 at ioplex.com> wrote:

> 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
>