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 <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
>>
