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/client/Invocation.Builder.html)
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
