Hi
The only thing I'm aware of is that it is of primary interest in case of
the asynchronous HTTP transport used to do the synchronous invocations.
I saw the related comment in ClientImpl code when I was updating the
jaxrs client code to match
Cheers, Sergey
On 11/08/16 08:45, Istvan Devai wrote:
Hi,
I'm using CXF with HTTP transport to use a SOAP webservice. All is fine,
however, when writing some unit tests to test the timeout behavior of
the CXF Client (eg simulating a server that is slow to respond, or
respond with 404), it is not behaving as set up via the HTTPClientPolicy.
In Detail:
1. As far as I've seen, the timeout values set up in HTTPCLientPolicy
are used in
org.apache.cxf.transport.http.URLConnectionHTTPConduit#setupConnection
to set up the underlying URLConnection instance. That is fine.
2. However, in ClientImpl, there is another wait happening in
org.apache.cxf.endpoint.ClientImpl#waitResponse that is controlled by
value set up in synchronousTimeout.
Therefore, the actual delay that will happen is the sum of
HttpClientPolicy.receiveTimeout + ClientImpl.synchronousTimeout
Questions:
1. What's the purpose of the synchronousTimeout in case of a synchronous
HTTP call, where the transport will either return the response (if it
falls within the HTTP transport's timeouts) or never after? Why wait
again in org.apache.cxf.endpoint.ClientImpl#waitResponse ?
2. When the webservice returns HTTP code 200, seemingly there is no
waiting happening, although the execution is again going over
org.apache.cxf.endpoint.ClientImpl#waitResponse. Seemingly this wait
here only kicks in for slow and/or HTTP codes >400. What's the
reason/intention behind that?
3. What will happen if I set the synchronousTimeout to 0? Will I be able
to achieve that there is no additional delay apart from the timeout set
up in the HTTP transport?
Thank you for your help!
Kind regards,
Istvan Devai
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
