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 <sberyoz...@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.in...@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 <sberyoz...@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
>
