[jcifs] java.io.IOException: Failed to establish session

Adam Morgan adam.morgan at Q1Labs.com
Wed Jul 14 06:19:11 MDT 2010


Hi Mike

 

Thanks for the responses - it is appreciated.  I'm sending the packet
capture in an email to you only.  Here's the stack trace.  I will
include these from the get go next time :)

 

java.io.IOException: Failed to establish session with
0.0.0.0<00>/172.16.155.153

        at jcifs.smb.SmbTransport.ssn139(SmbTransport.java:230)

        at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:247)

        at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:309)

        at jcifs.util.transport.Transport.run(Transport.java:232)

        at java.lang.Thread.run(Thread.java:619)

 

        at jcifs.util.transport.Transport.run(Transport.java:249)

        at java.lang.Thread.run(Thread.java:619)

 

        at jcifs.util.transport.Transport.connect(Transport.java:154)

        at jcifs.smb.SmbTransport.connect(SmbTransport.java:297)

        at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)

        at jcifs.smb.SmbFile.doConnect(SmbFile.java:906)

        at jcifs.smb.SmbFile.connect(SmbFile.java:949)

        at jcifs.smb.SmbFile.connect0(SmbFile.java:875)

        at jcifs.smb.SmbFile.queryPath(SmbFile.java:1328)

        at jcifs.smb.SmbFile.exists(SmbFile.java:1410)

        at
com.q1labs.semsources.sources.windowsiis.smbtail.foldermonitor.jcifs.Smb
RemoteFile.exists(SmbRemoteFile.java:184)

        at
com.q1labs.semsources.sources.windowsiis.smbtail.foldermonitor.FolderMon
itor.processFolder(FolderMonitor.java:401)

        at
com.q1labs.semsources.sources.windowsiis.smbtail.foldermonitor.FolderMon
itor.run(FolderMonitor.java:492)

        at java.lang.Thread.run(Thread.java:619)

 

Thanks

 

Adam

 

-----Original Message-----
From: Michael B Allen [mailto:ioplex at gmail.com] 
Sent: Tuesday, July 13, 2010 6:10 PM
To: Adam Morgan
Cc: jcifs at lists.samba.org
Subject: Re: [jcifs] java.io.IOException: Failed to establish session

 

Hi Adam,

 

If it immediately connects successfully after you restart the JVM,

then that sound like a bug in JCIFS. It sounds like the transport

state is not being correctly reset under some condition. I will have

to try to replicate this issue at my end. I have added this issue to

the TODO for further investigation.

 

If you have a capture, by all means send it to me (but do NOT post

packet captures to the mailing list). I might be able to quickly spot

the problem.

 

Also, generally, if you are seeing an error, usually it's a good idea

to post the corresponding stack trace or error message or whatever

error information you have.

 

Mike

 

-- 

Michael B Allen

Java Active Directory Integration

http://www.ioplex.com/

 

On Tue, Jul 13, 2010 at 9:41 AM, Adam Morgan <adam.morgan at q1labs.com>
wrote:

> Thanks Mike.  Musta been a Friday thing. More to this... now that the
exception is being passed on as expected we're seeing the underlying
issue and this is my next query.

> 

> We're doing some tests to simulate network connectivity disappearing.
Everything connects as expected initially.  Then we drop the network
adapter on the windows server so that our client cannot connect (or will
drop a current connection).  We then go into a reconnect loop until the
adapter is brought back up.  At this point, if the period of disconnect
is relatively short (ie a minute) the client will pick up where it left
off.

> 

> An issue seems to arise when the disconnection is prolonged.  I cannot
be certain of a more specific duration unfortunately.  When it is
prolonged, even once the server is back up, the client falls into a
state where it cannot connect.  I have debugged, and have tracked it
down to SmbTransport.ssn139().  It does the readn() on line 196, then
falls to line 211, case "NbtException.CALLED_NOT_PRESENT".  Resulting in
an exception from line  230.

> 

> The server box is absolutely available at this time, there's no
firewall issue, and if I restart the JVM, the client will reconnect.
Can u shed any light?  I can send u a tcpdump packet capture if this is
helpful.

> 

> Thanks

> 

> Adam

> 

> -----Original Message-----

> From: Michael B Allen [mailto:ioplex at gmail.com]

> Sent: Saturday, July 10, 2010 3:42 AM

> To: Adam Morgan

> Cc: jcifs at lists.samba.org

> Subject: Re: [jcifs] java.io.IOException: Failed to establish session

> 

> On Fri, Jul 9, 2010 at 9:25 AM, Adam Morgan <adam.morgan at q1labs.com>
wrote:

>> Thank you for the response Mike.  However, I'm not sure this will fix
my issue.  This will just log the exception to STDERR unless I'm
mistaken.  Is there no way to pass the exception up the stack to my
code?  Else there's no graceful way to handle the error.

>> 

>> Thoughts?

> 

> Hi Adam,

> 

> The default log.level is 1 and of course you can direct the log to a

> file. So the patch is correct. It will no longer clutter the console

> or application logs.

> 

> As for the "way to handle the error", if you study Transport.java

> closely you'll see that the exception is saved and then re-thrown in

> connect() unless the error happens after the connect timeout has

> expired in which case the calling thread will get a "Connection

> timeout" exception instead. Then by the time the "Failed to establish

> session" is thrown afterward, the caller will have moved on and so the

> exception is just logged and discarded as trying to do otherwise would

> be redundant.

> 

> Mike

> 

>> 

>> -----Original Message-----

>> From: Michael B Allen [mailto:ioplex at gmail.com]

>> Sent: Thursday, July 08, 2010 5:11 PM

>> To: Adam Morgan

>> Cc: jcifs at lists.samba.org

>> Subject: Re: [jcifs] java.io.IOException: Failed to establish session

>> 

>> Hi Adam,

>> 

>> That is indeed a mistake. The code should read:

>> 

>> 243                         if (log.level >= 2)

>> 244                             ex0.printStackTrace(log);

>> 

>> I have adjusted this in my local copy and it will be included in the

>> next release.

>> 

>> Thanks for the feedback.

>> 

>> Mike

>> 

>> On Wed, Jul 7, 2010 at 11:03 AM, Adam Morgan <adam.morgan at q1labs.com>
wrote:

>>> Hello

>>> 

>>> 

>>> 

>>> I'm running into an issue related to network connectivity.  We've
setup a

>>> windows box with samba and are connecting successfully with a
client.  We

>>> have a script running on the windows box to periodically turn off
the

>>> network adapter.  This is resulting in an exception being written to
STDOUT

>>> by the jcifs library, but the issue is never elevated to our code so
we

>>> cannot handle it gracefully (ie try a reconnect).  We're not doing
anything

>>> funky with configuration, just using the API in vanilla mode.

>>> 

>>> 

>>> 

>>> Here's the exception:

>>> 

>>> 

>>> 

>>> java.io.IOException: Failed to establish session with

>>> 0.0.0.0<00>/172.16.30.183

>>> 

>>>     at jcifs.smb.SmbTransport.ssn139(SmbTransport.java:230)

>>> 

>>>     at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:247)

>>> 

>>>     at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:309)

>>> 

>>>     at jcifs.util.transport.Transport.run(Transport.java:232)

>>> 

>>>     at java.lang.Thread.run(Thread.java:619)

>>> 

>>> 

>>> 

>>> I see in jcifs.util.transport.Transport, line 243, that the
exception is

>>> being printed to STDOUT.

>>> 

>>> 

>>> 

>>> Can u explain why this exception isn't passed on up thru to the code
that is

>>> using the API so we can handle it gracefully?  I've seen other
timeout

>>> exceptions that DO get passed up the chain so what might be making
this one

>>> not get passed up?

>>> 

>>> 

>>> 

>>> Thanks

>>> 

>>> 

>>> 

>>> Adam

>> 

>> 

>> 

>> --

>> Michael B Allen

>> Java Active Directory Integration

>> http://www.ioplex.com/

>> 

> 

> 

> 

> --

> Michael B Allen

> Java Active Directory Integration

> http://www.ioplex.com/

> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20100714/02f87c8a/attachment-0001.html>


More information about the jCIFS mailing list