[jcifs] Re: SmbException in jcifs-1.2.7
Michael B Allen
mba2000 at ioplex.com
Fri Mar 24 15:44:42 GMT 2006
Did you ever try this Rainer?
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
>
More information about the jcifs
mailing list