cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Error building CXF from source (trunk checkout) [64 Bit Vista]
Date Wed, 30 Jun 2010 19:01:25 GMT
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:


> > 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
> et.SocketAddress%29 and
> 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

View raw message