cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: (Very) Frequent Test Failures on Windows
Date Thu, 07 Jun 2007 22:37:00 GMT
There may be some problem with already configured ports.
However, if you are just using "http" it should be fine.

The *big* problem is that there is a *static* cache for ports which is
shared across all buses in a JVM.
 
 (previously, some of the https tests were working because they
  were using unprotected ports which were already configured
  by some other test.)

This "MapTest" test is written such that if the System property "os.name" is
Windows 2000, the test starts its server off "inProcess", and there in 
lies the
problem.

If the port is already in use and it may
shutdown by some other test in the JVM, I think you might get this error.

Until we figure out a strategy to mitigate this problem for a barage of
system test servers in process, it is safer to start all your
servers in separate processes (JVMs) or make sure you use unique port
numbers for all servers.  (Although, that still won't avoid Address In 
Use errors
by running two mvn tests on the same machine. )

Cheers,
-Polar

Glynn, Eoghan wrote:
>
>   
>> -----Original Message-----
>> From: Paibir, Ajay [mailto:ajay.paibir@iona.com] 
>> Sent: 07 June 2007 19:22
>> To: cxf-dev@incubator.apache.org
>> Subject: RE: (Very) Frequent Test Failures on Windows 
>>
>> Hi 
>>
>> Yes I am seeing this too even after a clean build/repository. 
>> Also I have two more test showing similar failure.
>>
>> org.apache.cxf.systest.ws.rm.DecoupledClientServerTest
>> org.apache.cxf.systest.ws.policy.RMPolicyTest
>>
>> It seems the common subset for all the three tests is the 
>> decoupled Http.
>>
>> Any changes went in around this area? I have all updates 
>> before DanK's commit.
>>     
>
>
> Well the reworked HTTPS config patch also went into trunk this morning.
>
> Even though the decoupled tests use plain ol' HTTP as opposed to HTTPS,
> this patch involves some rework of the JettyHTTPServerEngine logic in
> the insecure case also.
>
> Have you tried running the tests against r545110 (i.e. last revision
> before the reworked HTTPS config patch was applied).
>
> Cheers,
> Eoghan
>
>  
>   
>> Regards
>> Ajay
>>
>>
>>     
>>> -----Original Message-----
>>> From: Andrea Smyth [mailto:andrea.smyth@iona.com]
>>> Sent: 07 June 2007 19:10
>>> To: cxf-dev@incubator.apache.org
>>> Subject: (Very) Frequent Test Failures on Windows
>>>
>>> Hi all,
>>>
>>> I am seeing a lot of errors now in the system tests - in areas that 
>>> should at all be affected by stuff that I have modified in 
>>>       
>> my working 
>>     
>>> copy.
>>> MAPTest for example, and AddressingOptionalPolicyTest, all with:
>>>
>>> Caused by: org.apache.cxf.interceptor.Fault: Could not send Message.
>>>     at
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSen
>>> derEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
>>>     at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
>>> terceptorChain.java:147)
>>>     at 
>>>       
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:249)
>>     
>>>     at 
>>>       
>> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:200)
>>     
>>>     at
>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>>     at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.
>>> java:134)
>>>     ... 26 more
>>> Caused by: java.net.SocketException: Unexpected end of file from 
>>> server
>>>     at
>>> sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:684)
>>>     at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:554)
>>>     at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:571)
>>>     at
>>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(Htt
>>> pURLConnection.java:940)
>>>     at
>>>
>>>       
>> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
>>     
>>>     at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.
>>> handleResponse(HTTPConduit.java:1767)
>>>     at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.
>>> doClose(HTTPConduit.java:1690)
>>>     at
>>> org.apache.cxf.io.AbstractCachedOutputStream.close(AbstractCac
>>> hedOutputStream.java:114)
>>>     at
>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit
>>> .java:66)
>>>     at
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSen
>>> derEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>     ... 31 more
>>>
>>> Could this be related to the patch affecting the http listener?
>>> Is anyone else seeing these?
>>>
>>> Andrea.
>>>
>>> ----------------------------
>>> IONA Technologies PLC (registered in Ireland) Registered
>>> Number: 171387 Registered Address: The IONA Building, 
>>>       
>> Shelbourne Road, 
>>     
>>> Dublin 4, Ireland
>>>
>>>       
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, 
>> Dublin 4, Ireland
>>
>>     
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>   

Mime
View raw message