cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mandy Warren <mandys.in...@gmail.com>
Subject Re: WebClient fire & forget
Date Tue, 16 Dec 2014 16:41:02 GMT
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 <sberyozkin@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 <mandys.inbox@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 <sberyozkin@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
> 

Mime
View raw message