Hi Istvan
On 15/08/16 10:19, [email protected] wrote:
Hi Sergey,
Yes indeed, in the CXF source, this comment is next to this timeout:
"When a synchronous request/response invoke is done using an
asynchronous transport mechanism, this is the timeout used for waiting
for the response. Default is 60 seconds."
The question here however, why does a regular HTTP transport qualify as
an async transport mechanism? I mean, how the the HTTP conduit works is
that it creates a connection, waits for a reply with a given timeout and
if the timeout fails, it raises an exception.
When a cxf-rt-transport-http-hc is added as a dependency then the
synchronous invocations can be done with an asynchronous HTTP Client (as
opposed to HTTPUrlConnection).
I'm not sure if HTTPUrlConnection-based conduit can be used in JAX-WS
for the async calls, example, Dan may've added some thread-storage there
emulating the async transport, to support JAX-WS async calls,
Dan can you clarify please :-) ?
After such an exception
happens, what's the point of waiting again in ClientImpl in the method
ClientImpl#waitResponse? Since the conduit already did what it could, no
response will ever come, and it just becomes a useless wait as far as I
can tell..
I think what should happen, is that after the conduit raises an
exception, that is placed into the Exchange and in turn, ClientImpl will
see that an exception happened while processing the response and will
never go into ClientImpl#waitResponse uselessly.
Do you think I should raise this on the dev list or raise a ticket?
Thanks for trying not to generate the 'noise' on the dev list :-). I
think this discussion qualifies for the dev list no problems but FYI all
the devs are on the users list, as far as I know.
Lets wait and see what Dan has to say
Thanks, Sergey
Thanks,
Istvan
On 2016-08-11 11:04, Sergey Beryozkin wrote:
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/
