You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mandy Warren <ma...@gmail.com> on 2014/12/05 08:51:30 UTC
WebClient fire & forget
Hi,
We currently use WebClient (.put/.post/.get etc) for sending messages synchronously from Rest service 1 to Rest service 2. We now have a requirement to send a message to Rest service 2 but not bother waiting until that service completes as it may take a long time i.e. a fire & forget scenario.
So assume I am using a "post" to send data to Rest service 2 it looks like I would use public <T> Future<T> post(javax.ws.rs.client.InvocationCallback<T> callback). But given I don't want / care about whether the call has been successful or not I presume I just declare a an javax.ws.rs.client.InvocationCallback which does nothing and I just ignore the Future?
Also, let's say that Rest service 2 can take up to 10 seconds to complete it's work, I don't want Rest service 1 to hang around waiting for the callback so would I just specify a short receive timeout in the WebClient configuration and let Rest Service 2 fail when it tries to send a response back?
Apologies if this is obvious, I just haven't used the async behaviour before.
Many thanks
Mandy
Re: WebClient fire & forget
Posted by Mandy Warren <ma...@gmail.com>.
Setting an exchange property is a great idea.. I will try that :-)
Many thanks
Sent from a mobile device
> On 16 Dec 2014, at 12:01, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> Hi Mandy
>> On 16/12/14 11:30, Mandy Warren wrote:
>> This worked fine, many thanks. Just a query about the option to use the same thread instead of spawning a new one... Does that mean service 1 waits til service 2 completes execution or does it return at an earlier phase?
>>
>> I ask because currently our pattern is to place data about the call into a thread local at the RECEIVE phase of service 2 and with the standard OnewayRequest invocation this data disappears because a new thread is created. So I noticed the option to stay on the same thread which would solve this issue but wasn't sure when control would be handed back to service 1.
> I believe running oneway requests on the same thread would only emulate the one-way style, 202 would still be returned. I have to admit the purpose of some of the code in OneWayProcessorInterceptor is not clear to me but I guess the same thread execution would provide little benefit the client code may be after.
> I think it would be better setting an exchange property rather than working with TL, this property would come back to the out interceptor even if a new thread is spawned (I honestly believe into it :-))
>
> Give it a try please
> Cheers, Sergey
>
>
>> Many thanks
>> Mandy
>>
>> Sent from a mobile device
>>
>>> On 12 Dec 2014, at 14:19, Mandy Warren <ma...@gmail.com> wrote:
>>>
>>> Many thanks Sergey I will give this a try and let you know..
>>>
>>> Sent from a mobile device
>>>
>>>> On 5 Dec 2014, at 10:44, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>>
>>>> Hi Mandy
>>>>
>>>> If the server is CXF based then doing
>>>> WebClient.header("OnewayRequest", "true") will work.
>>>>
>>>> Give it a try please,
>>>>
>>>> Cheers, Sergey
>>>>> On 05/12/14 07:51, Mandy Warren wrote:
>>>>> Hi,
>>>>>
>>>>> We currently use WebClient (.put/.post/.get etc) for sending messages synchronously from Rest service 1 to Rest service 2. We now have a requirement to send a message to Rest service 2 but not bother waiting until that service completes as it may take a long time i.e. a fire & forget scenario.
>>>>>
>>>>> So assume I am using a "post" to send data to Rest service 2 it looks like I would use public <T> Future<T> post(javax.ws.rs.client.InvocationCallback<T> callback). But given I don't want / care about whether the call has been successful or not I presume I just declare a an javax.ws.rs.client.InvocationCallback which does nothing and I just ignore the Future?
>>>>>
>>>>> Also, let's say that Rest service 2 can take up to 10 seconds to complete it's work, I don't want Rest service 1 to hang around waiting for the callback so would I just specify a short receive timeout in the WebClient configuration and let Rest Service 2 fail when it tries to send a response back?
>>>>>
>>>>> Apologies if this is obvious, I just haven't used the async behaviour before.
>>>>>
>>>>> Many thanks
>>>>>
>>>>> Mandy
>
Re: WebClient fire & forget
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Mandy
On 16/12/14 11:30, Mandy Warren wrote:
> This worked fine, many thanks. Just a query about the option to use the same thread instead of spawning a new one... Does that mean service 1 waits til service 2 completes execution or does it return at an earlier phase?
>
> I ask because currently our pattern is to place data about the call into a thread local at the RECEIVE phase of service 2 and with the standard OnewayRequest invocation this data disappears because a new thread is created. So I noticed the option to stay on the same thread which would solve this issue but wasn't sure when control would be handed back to service 1.
>
I believe running oneway requests on the same thread would only emulate
the one-way style, 202 would still be returned. I have to admit the
purpose of some of the code in OneWayProcessorInterceptor is not clear
to me but I guess the same thread execution would provide little benefit
the client code may be after.
I think it would be better setting an exchange property rather than
working with TL, this property would come back to the out interceptor
even if a new thread is spawned (I honestly believe into it :-))
Give it a try please
Cheers, Sergey
> Many thanks
> Mandy
>
> Sent from a mobile device
>
>> On 12 Dec 2014, at 14:19, Mandy Warren <ma...@gmail.com> wrote:
>>
>> Many thanks Sergey I will give this a try and let you know..
>>
>> Sent from a mobile device
>>
>>> On 5 Dec 2014, at 10:44, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>>> Hi Mandy
>>>
>>> If the server is CXF based then doing
>>> WebClient.header("OnewayRequest", "true") will work.
>>>
>>> Give it a try please,
>>>
>>> Cheers, Sergey
>>>> On 05/12/14 07:51, Mandy Warren wrote:
>>>> Hi,
>>>>
>>>> We currently use WebClient (.put/.post/.get etc) for sending messages synchronously from Rest service 1 to Rest service 2. We now have a requirement to send a message to Rest service 2 but not bother waiting until that service completes as it may take a long time i.e. a fire & forget scenario.
>>>>
>>>> So assume I am using a "post" to send data to Rest service 2 it looks like I would use public <T> Future<T> post(javax.ws.rs.client.InvocationCallback<T> callback). But given I don't want / care about whether the call has been successful or not I presume I just declare a an javax.ws.rs.client.InvocationCallback which does nothing and I just ignore the Future?
>>>>
>>>> Also, let's say that Rest service 2 can take up to 10 seconds to complete it's work, I don't want Rest service 1 to hang around waiting for the callback so would I just specify a short receive timeout in the WebClient configuration and let Rest Service 2 fail when it tries to send a response back?
>>>>
>>>> Apologies if this is obvious, I just haven't used the async behaviour before.
>>>>
>>>> Many thanks
>>>>
>>>> Mandy
>>>
Re: WebClient fire & forget
Posted by Mandy Warren <ma...@gmail.com>.
This worked fine, many thanks. Just a query about the option to use the same thread instead of spawning a new one... Does that mean service 1 waits til service 2 completes execution or does it return at an earlier phase?
I ask because currently our pattern is to place data about the call into a thread local at the RECEIVE phase of service 2 and with the standard OnewayRequest invocation this data disappears because a new thread is created. So I noticed the option to stay on the same thread which would solve this issue but wasn't sure when control would be handed back to service 1.
Many thanks
Mandy
Sent from a mobile device
> On 12 Dec 2014, at 14:19, Mandy Warren <ma...@gmail.com> wrote:
>
> Many thanks Sergey I will give this a try and let you know..
>
> Sent from a mobile device
>
>> On 5 Dec 2014, at 10:44, Sergey Beryozkin <sb...@gmail.com> wrote:
>>
>> Hi Mandy
>>
>> If the server is CXF based then doing
>> WebClient.header("OnewayRequest", "true") will work.
>>
>> Give it a try please,
>>
>> Cheers, Sergey
>>> On 05/12/14 07:51, Mandy Warren wrote:
>>> Hi,
>>>
>>> We currently use WebClient (.put/.post/.get etc) for sending messages synchronously from Rest service 1 to Rest service 2. We now have a requirement to send a message to Rest service 2 but not bother waiting until that service completes as it may take a long time i.e. a fire & forget scenario.
>>>
>>> So assume I am using a "post" to send data to Rest service 2 it looks like I would use public <T> Future<T> post(javax.ws.rs.client.InvocationCallback<T> callback). But given I don't want / care about whether the call has been successful or not I presume I just declare a an javax.ws.rs.client.InvocationCallback which does nothing and I just ignore the Future?
>>>
>>> Also, let's say that Rest service 2 can take up to 10 seconds to complete it's work, I don't want Rest service 1 to hang around waiting for the callback so would I just specify a short receive timeout in the WebClient configuration and let Rest Service 2 fail when it tries to send a response back?
>>>
>>> Apologies if this is obvious, I just haven't used the async behaviour before.
>>>
>>> Many thanks
>>>
>>> Mandy
>>
Re: WebClient fire & forget
Posted by Mandy Warren <ma...@gmail.com>.
Many thanks Sergey I will give this a try and let you know..
Sent from a mobile device
> On 5 Dec 2014, at 10:44, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> Hi Mandy
>
> If the server is CXF based then doing
> WebClient.header("OnewayRequest", "true") will work.
>
> Give it a try please,
>
> Cheers, Sergey
>> On 05/12/14 07:51, Mandy Warren wrote:
>> Hi,
>>
>> We currently use WebClient (.put/.post/.get etc) for sending messages synchronously from Rest service 1 to Rest service 2. We now have a requirement to send a message to Rest service 2 but not bother waiting until that service completes as it may take a long time i.e. a fire & forget scenario.
>>
>> So assume I am using a "post" to send data to Rest service 2 it looks like I would use public <T> Future<T> post(javax.ws.rs.client.InvocationCallback<T> callback). But given I don't want / care about whether the call has been successful or not I presume I just declare a an javax.ws.rs.client.InvocationCallback which does nothing and I just ignore the Future?
>>
>> Also, let's say that Rest service 2 can take up to 10 seconds to complete it's work, I don't want Rest service 1 to hang around waiting for the callback so would I just specify a short receive timeout in the WebClient configuration and let Rest Service 2 fail when it tries to send a response back?
>>
>> Apologies if this is obvious, I just haven't used the async behaviour before.
>>
>> Many thanks
>>
>> Mandy
>
Re: WebClient fire & forget
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Mandy
If the server is CXF based then doing
WebClient.header("OnewayRequest", "true") will work.
Give it a try please,
Cheers, Sergey
On 05/12/14 07:51, Mandy Warren wrote:
> Hi,
>
> We currently use WebClient (.put/.post/.get etc) for sending messages synchronously from Rest service 1 to Rest service 2. We now have a requirement to send a message to Rest service 2 but not bother waiting until that service completes as it may take a long time i.e. a fire & forget scenario.
>
> So assume I am using a "post" to send data to Rest service 2 it looks like I would use public <T> Future<T> post(javax.ws.rs.client.InvocationCallback<T> callback). But given I don't want / care about whether the call has been successful or not I presume I just declare a an javax.ws.rs.client.InvocationCallback which does nothing and I just ignore the Future?
>
> Also, let's say that Rest service 2 can take up to 10 seconds to complete it's work, I don't want Rest service 1 to hang around waiting for the callback so would I just specify a short receive timeout in the WebClient configuration and let Rest Service 2 fail when it tries to send a response back?
>
> Apologies if this is obvious, I just haven't used the async behaviour before.
>
> Many thanks
>
> Mandy
>