[jcifs] ConnectException: timeout

Michael B Allen mba2000 at ioplex.com
Wed Mar 21 14:40:34 GMT 2007

On Wed, 21 Mar 2007 10:21:56 -0400
Jake Goulding <goulding at vivisimo.com> wrote:

> I tried to send the below message to the list, but it was bounced as 
> spam. Any tips?
> > Diagnostic-Code: X-Postfix; Command died with status 1:
> >     "/usr/local/bin/stopspam post jcifs". Command output: Mail rejected by
> >     content filter

Beats me. Who knows what the samba guys go through to try and filter
spam. Sounds like a problem of 'content'. I do see you have a character
after the 'Search Done Right' that isn't rendered properly by my mailer
and in vim it looks like a '<99>'. But who knows. We're clearly loosing
the spam-war.

I've pruned some content, hopefully it will go through.

> > I recently found a few of these exceptions being thrown that were not 
> > caught by my application. Does jCIFS start a separate thread to do the 
> > actual communication with the server, and is this exception thrown 
> > from that thread? That would explain why my various catch statements 
> > would have ignored this. Is there a way to get this exception back 
> > into the thread that it is associated with?
> >
> >
> > java.net.ConnectException: Connection timed out: connect
> >        at java.net.PlainSocketImpl.socketConnect(Native Method)
> >        at jcifs.smb.SmbTransport.ssn139(SmbTransport.java:178)
> >        at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:237)
> >        at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:302)
> >        at jcifs.util.transport.Transport.run(Transport.java:240)
> >        at java.lang.Thread.run(Unknown Source)

Yes, JCIFS uses a separate thread to connect and read responses. This is
because there is currently no way to multiplex I/O with multiple callers
(the NIO package is not suitable). The transport thread is also used to
do the socket connect because it does not support timeouts.

All of this should be of no consequence to the user since the exception
*should* be seamlessly passed back to the caller that initiated the
connect. If you look at the jcifs.util.transport.Transport.java and
jcifs.smb.SmbTransport.java classes somewhere in there you'll see that
any exception thrown by the transport thread is saved and then rethrown
by the caller's thread.


Michael B Allen
PHP Active Directory Kerberos SSO

More information about the jcifs mailing list