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
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html
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
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/clisystests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRS20ClientServerBookTest.javaent/Invocation.Builder.html)
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
