Hi Andrew,
I think it could be a CXF bug.
Here is a way to set the ClientPolicy into the dispatch by writing a
custom Feature.
public class HttpClientConfigFeature extends AbstractFeature {
HttpClientPolicy myConfig;
@Override
public void initialize(Client client, Bus bus) {
Conduit conduit = client.getConduit();
if (conduit instanceof HttpConduit && myConfig != null) {
HttpConduit httpConduit = (HttpConduit)conduit;
httpConduit.setClient(myConfig);
}
super.initialize(client, bus);
}
...
}
You need to configure this feature into with below configuration
<client id="MockClient" xmlns="http://cxf.apache.org/jaxws"
xmlns:ns="http://cathdb.info/FuncNet_0_1/"
serviceName="ns:XXXService"
endpointName="ns:MockPort"
wsdlLocation="wsdl/hello_world.wsdl"
address=YOUR_ADDESS
serviceClass=DUMMYCLASS >
<features>
<bean xmlns="http://www.springframework.org/schema/beans"
class="HttpClientConfigFeature">
<property name="myConfig" ref="refConfig">
</property>
</bean>
</features>
</client>
Willem
Andrew Clegg wrote:
> Unfortunately not -- it still times out after 60s during the get()
> call, presumably since it's still using the same underlying transport.
>
> Actually server-side asynchronous operations are on my to-do list for
> the future, so showstopper was perhaps a bit of an exaggeration. But
> I'm trying to get some load tests passing before this weekend for a
> release, and async ops certainly won't happen by then...
>
> Also, I just discovered a workaround -- specifying the timeout in the
> WSDL does work for my dispatch objects:
>
> <wsdl:service name="MockService">
> <wsdl:port binding="tns:MockBinding" name="MockPort">
> <soap:address location="http://localhost:9001/Mock" />
> <http-conf:client ReceiveTimeout="0" />
> </wsdl:port>
> </wsdl:service>
>
> Even though the identical element in cxf.xml doesn't:
>
> <http-conf:conduit id="Mock"
> name="{http://cathdb.info/FuncNet_0_1/}MockPort.http-conduit">
> <http-conf:client ReceiveTimeout="0" />
> </http-conf:conduit>
>
> http-conf refers to
> http://cxf.apache.org/transports/http/configuration both times.
>
> Not ideal, because I can't do this for other people's services without
> downloading their WSDLs and modifying them. If any of the dev team
> read this and confirm that it's a bug, and not pilot error, let me
> know and I'll log a JIRA with a test case.
>
> Or if there is some arcane way of modifying the ClientPolicy for a
> Dispatch, then please let me know, as this would be my preferred
> approach.
>
> Cheers,
>
> Andrew.
>
>
> 2008/10/29 Glen Mazza <[EMAIL PROTECTED]>:
>> Pardon the non-answer, but perhaps using an async client (either Dispatch or
>> JAX-WS based) may be the solution for what you need anyway. Check the first
>> paragraph of here: http://www.jroller.com/gmazza/date/20080308
>>
>> HTH,
>> Glen
>>
>>
>> Andrew Clegg wrote:
>>> I'm working with services that send fairly large chunks of XML around,
>>> and I'm currently testing the client. I have a mock service using the
>>> Provider interface which just waits for a pre-set interval then
>>> returns some XML.
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/Dispatch-clients-don%27t-read-http%3Aconduit-timeout-settings...-Showstopper--tp20228606p20230670.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>