cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <ashaki...@talend.com>
Subject RE: Timeouts set up in httpClientPolicy vs ClientImpl.synchronousTimeout
Date Sun, 21 Aug 2016 16:47:02 GMT
Hi,

Take into account that CXF can communicate synchronously using native async protocols like
JMS or UDP.
I guess that ClientImpl.synchronousTimeout was designed for such cases to avoid infinite waiting
of the response on the client side.

Regards,
Andrei.

> -----Original Message-----
> From: zoldnap@freemail.hu [mailto:zoldnap@freemail.hu]
> Sent: Montag, 15. August 2016 11:19
> To: users@cxf.apache.org
> Subject: Re: Timeouts set up in httpClientPolicy vs
> ClientImpl.synchronousTimeout
> 
> 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. 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,
> 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#setupConnectio
> >> n 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
> >>
> >
> >

Mime
View raw message