Charlie, Alan,

For what its worth, I spent some time looking into this, and with Java, it is virtually impossible to  cause a connect timeout to a server on the same system that the connect (client) is running on.  The minimum value that you can set for a connect timeout in Java is one millisecond, and my connect tests succeeded within 1 millisecond way over 99 percent of the time.  Also, I could not get connects to reliably fail with a timeout even on my LAN.  Setting the timeout to 1 ms, from 50 to 75 percent of the connections still succeeded.  This was on both Windows XP and Linux with both running Java 1.6.  So, unless there is some trick, I don't think that you are going to be able to reliably get this test to pass, without connecting to a server on the Internet. 

For the record,  the Java code appeared to do better over the Internet than on the Lan, so I speculate that there is some fault tolerance going on in Java by looking at the address, but I do not know this for sure.  Java really didn't get a good clock until Java 1.5, so this might be something that could be requested from Sun if they are not already planning on upgrading this.  I ran my same tests in Python 2.5 and Python is able to be much more accurate on connect timeouts. Also, I noticed that timeout was added to Python in Python 2.3, so it may be a good idea to leave it off of the Jython 2.2 and add it the next release. 


-----Original Message-----
From: Alan Kennedy <>
To: Charlie Groves <>
Cc: JythonDevelopers <>
Sent: Wed, 25 Jul 2007 1:48 pm
Subject: Re: [Jython-dev] test_socket and test_select_new failures on Mac on trunk

>> To make the server thread refuse incoming connections, and thus make the
>> test pass with the correct timeout exception, it needs to bind to but
>> not listen to the port. So this definition of the test should work

> This still listens for incoming connections; bind on a ServerSocket
> calls listen internally. I don't see a way to separate out binding
> from listening from Java, so I'm thinking we may just have to drop
> this test.

Yes, indeed there seems to be no way to bind but not listen on a port.

The test as-it-was was passing on my machine because the timeout I used
was too short for a connection to be successfully formed. When I
lengthen the timeout to 1 second, the connect succeeds, thus failing the

We could try to find a timeout value that is short enough to guarantee
failure on every platform. But that might not be possible, given the
multi-threading nature of the test, and the fact that it's being run on
multi-cpu machines.

Or we could try to connect to a machine on the internet, e.g., with a very low timeout, which is pretty much guaranteed
to fail. But that would require our test machine having internet access,
and thus our tests would not be self-contained.

Maybe we need to drop this test.

Which is a pity, because the use case is something that needs testing. I
introduced the test because it tests for a bug I found. When in timeout
mode, the socket implementation needs to use the method, which takes a timeout parameter,
instead of the java.nio.channels.SocketChannel.connect() method, which
does not take a timeout parameter. My original implementation used the
latter method instead of the former, thus timeouts on client connects
were not being honoured, as I recorded in the checkin comments for the
fix + unit test.

Still, rather than simply delete the test, I'd prefer to leave it in
place, but commented out. At least that way it can serve as
documentation that timeout on client connects is something that needs to
be manually tested, or at least noted as a potential source of problems.



This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
Jython-dev mailing list

Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.