You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Istvan Devai <is...@istvandevai.com> on 2016/08/11 07:45:17 UTC
Timeouts set up in httpClientPolicy vs ClientImpl.synchronousTimeout
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
RE: Timeouts set up in httpClientPolicy vs
ClientImpl.synchronousTimeout
Posted by Andrei Shakirin <as...@talend.com>.
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
> >>
> >
> >
Re: Timeouts set up in httpClientPolicy vs
ClientImpl.synchronousTimeout
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Istvan
On 15/08/16 10:19, zoldnap@freemail.hu 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/
Re: Timeouts set up in httpClientPolicy vs
ClientImpl.synchronousTimeout
Posted by "zoldnap@freemail.hu" <zo...@freemail.hu>.
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#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
>>
>
>
Re: Timeouts set up in httpClientPolicy vs
ClientImpl.synchronousTimeout
Posted by Sergey Beryozkin <sb...@gmail.com>.
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/