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:14:52 GMT
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

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