cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Async methods for JAX-RS WebClient
Date Sun, 23 Sep 2012 17:56:54 GMT
On 23/09/12 18:14, Sergey Beryozkin wrote:
> Hi Dan
> On 21/09/12 19:27, Daniel Kulp wrote:
>> Sergey, (and others)
>> I just committed some initial support for some async methods to the
>> WebClient. Can you take a look at that change and make sure it all
>> makes sense? I only have a "get" method in there right now, but it
>> should be fairly trivial now to add the others that would map to the
>> new doInvokeAsync method. Just want to make sure it looks ok first.
> It is a very good start, thanks for starting to look into it. I think I
> will push some of the code to AbstractClient once I get a better
> understanding of what is going on, for proxies to get the async support
> too.
> Other than that, I wonder if we should introduce an "async()" method
> which would return
> that would let us support the async style of invocation completely in
> line with the way JAX-RS 2.0 does it, example:
> WebClient wc = WebClient.create("address");
> wc.async().get(callback); // etc
> (async() in JAX-RS 2.0 is in

I  added an empty AsyncInvoker implementation, with 
async().get(InvocationCallback) also working for now :-).

Wow, it's really happening thanks to the addition of the HTTP async 
transport :-)

Thanks, Sergey

> In addition to that we can indeed add simple shortcuts, one per every
> main method, or for those which are more likely to participate in async
> flows, say for get/post/put, to let users 'save' on typing 'async()' for
> few mainstream cases
>> I'm a little concerned about the "state" objects in the WebClient. I
>> assume WebClients aren't supposed to be thread safe (that's OK).
>> However, can a WebClient be used to make multiple calls? What would
>> you expect in the case where a WebClient makes multiple async calls?
> By default WebClient is not thread safe, but the thread-safety can be
> activated by a threadSafe flag, it can be set on the client factory
> bean, or passed to a WebClient factory method. Have a look please at
> JAXRSMultithreadedClientTest. A thread-local map is then used to keep a
> per-invocation state.
> WebClient keeps the state because it emulates the 'browsing' process, so
> at any moment it (a single instance) can move back or forward - but that
> requires an extra support for the thread safety. 2.0 client interface is
> different, no 'browsing' style is there, so it may be much simpler to
> deal with the thread safety, I'll fond out soon once I start
> implementing it :-)
> Cheers, Sergey

View raw message