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: [email protected] [mailto:[email protected]] > Sent: Montag, 15. August 2016 11:19 > To: [email protected] > 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 > >> > > > >
