[jcifs] About the long crawling time again...

[Allen, Michael B (RSCH)]

It doesn't look like jCIFS after all does it. The real problem here is that the PlainSocketImpl.connect() which is JDK code is hanging when I believe it should immediately throw the
NoRouteToHostException. An interesting test would be to write a very simple socket Java program to test on one of these "lame" hosts. If it too hangs on one of these hosts then you might have
discovered a bug in the JDK. I checked the bug database at http://developer.java.sun.com and didn't find anything with NoRouteToHostException and PlainSocketImpl.

I have a feeling that that's not it though. It would be a pretty hurrendous bug in Java. Notice how you had to hit Ctrl-C to get out of telnet because it hung? I think it's a network thing. Not
necessarily a misconfiguration issue but for example if you try to connect to an ip that simply isn't routable on the network it will hang. So maybe there is some kind of dynamic routing going on --
like dialup users. Some kind of hosts that pop-up, dynamically get's an IP which is added to a routing table somewhere, register a name with WINS, drop-off, the route get's dropped, but the WINS lease
doesn't expire for an hour or two. So the name lookup succeeds and then jCIFS fails trying to connect to the IP because it's not routed anymore or somesuch.

For example: If you pick some crazy IP out of the air and try and use that with jCIFS it will hang in the same way I bet. Like:

$ java List smb://192.166.8.6


[PS: I did find the bug about using the loopback address that's in the FAQ:
http://developer.java.sun.com/developer/bugParade/bugs/4471292.html]

> -----Original Message-----
> From:	torjo845 at student.liu.se [SMTP:torjo845 at student.liu.se]
> 
> 
> Yeah, that ip was to the host A828 which wasn't working.
> So basically the problem probably is in the network(or the jdk) and not jcifs?
> Ok, not much to do about it then. Just have to find a way to bypass it somehow... I'll try jdk1.4 and see what happens.
>