On Wednesday 30 June 2010 2:33:18 pm Jim Talbut wrote:
> On 30/06/2010 17:55, Daniel Kulp wrote:
> > Thus, if the test is failing, it's either successfully connecting to
> > something or the thrown fault is wrong.
>
> In which case it would appear that the thrown fault is wrong, but why
> not on your hudson builds?
Hudson is running on Linux so your linux experiments you list below apply.
:-)
> I also tried changing the port to one that I simply know isn't in use,
> in each the result is the same:
> java.lang.AssertionError: java.net.SocketTimeoutException
Interesting.
> > The TestUtil.getPortNumber("fake-port") gets a "unique" port number by
> > allocating a server socket, getting the port number, then immediately
> > closing it. Maybe it's taking a little extra time to close that port.
> > Also, try doing a printStackTrace on the caught exception prior to the
> > assert. I'd like to know the trace where the SocketTimeoutException is
> > coming from. According to javadocs, we SHOULD be getting the
> > ConnectException, not the SocketTimeoutException.
>
> Not sure I concur with your interpretation of the javadoc, both
> http://java.sun.com/javase/6/docs/api/java/net/Socket.html#connect%28java.n
> et.SocketAddress%29 and
> http://java.sun.com/javase/6/docs/api/java/net/URLConnection.html#connect%2
> 8%29 say that a SocketTimeoutException is returned if the timeout expires
> whilst connecting.
Well, I was looking at the javadoc for the ConnectException that says:
* Signals that an error occurred while attempting to connect a
* socket to a remote address and port. Typically, the connection
* was refused remotely (e.g., no process is listening on the
* remote address/port).
But I see where you are coming from as well. Nice to have things nice an
consistent. :-)
.......
> The interesting thing, found after a bit of experimentation at work
> today, is that trying to connect to a nonexistant localhost port on a
> Windows box takes ~1s to fail, but on either Linux or MacOS it fails
> immediately.
> So on Linux and MacOS you get a ConnectException because it has failed
> to connect, but on Windows it times out instead.
OK. So I guess the fix is to update the test to increase the timeout to 2
secs or so and also catch and allow the SocketTimeoutException. Want to
contribute a patch? (since you can test it on Windows and I cannot) :-)
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
