I just added an extension to the Client API in the trunk, see the
following unit test for an example:
https://jersey.dev.java.net/source/browse/*checkout*/jersey/trunk/jersey/test/com/sun/jersey/impl/client/AsyncHttpMethodTest.java
Currently the implementation is naive and creates a thread per request
without using a thread pool. I am sure some refactoring can be done to
improve the impl as well...
Paul.
Nick Stuart wrote:
> So are you thinking that this is something that will actually be
> implemented on the server side of things? Depending on the they type of
> client, or the type of parameter passed in? (ie Future<String>) I guess
> thinking about it that would make sense. My first reaction to this was
> to fire up a new thread on the client/requester to make the Resource
> call, but doing manual thread creation/management on the client webside
> of things makes me feel a bit nauseated and uncomfortable. Having the
> server still accept the request and just return immediately, and then do
> the processing, makes more sense though.
>
> And I have only taking a breif look into Guice, but will take a look at
> it some more to see some of the concepts they are using there.
>
> On 5/19/08, *Paul Sandoz* <Paul.Sandoz_at_sun.com
> <mailto:Paul.Sandoz_at_sun.com>> wrote:
>
> Hi Nick,
>
> Nick Stuart wrote:
>
> Hi all! I am trying to setup a simple resource that will handle
> a 'long winded' request. Basically I want to do a 'PUT' to
> create something that takes a while to get going. I don't really
> care about the return codes or anything and don't want to wait
> till the entire reuqest is done. Is there a 'best practice' way
> of doing this? This will be executing out of another Servlet
> that does some stuff before hand and will need fire this request
> off as well once it is done.
>
> Any thoughts or ideas on this? Only thing I've seen that
> mentions this is at
> http://blogs.sun.com/sandoz/entry/jersey_client_api near the
> bottom, but its only put there as a quick idea/thought. Has
> anything else been done for this?
>
>
> It was an idea of the general vision i want to head towards but i
> have not currently had any time to pursue it.
>
> Off the top of my head we could do something like this:
>
> AsyncWebResource ar = client.asyncResource("http://host/foo");
> Future<String> fs = ar.put(String.class);
>
> I don't think it is that hard to create a naive implementation that
> uses a thread-per-request, but the vision goes further to utilize
> Grizzly to get scalable services that are also clients of other
> services.
>
> Ideally i wanted to reuse the WebResource iface but i cannot do:
>
> WebResource a = client.resource("http://host/foo");
> Future<String> fs = ar.put(Future<String>.type);
>
> but obviously that will not work :-) but there may be a way using
> the the TypeLiteral class in Guice that Lars pointed me too (which
> incidentally we are attempting to include in the 311 API) but from a
> type safety perspective i am not sure it really improves things.
>
>
> Note that an alternative way to manage long requests is for the
> service to return immediately with a new URI that is a handle to the
> state of processing (a ticket-based pattern), which is obviously
> more work for both the client and service but can be the more
> appropriate thing to do in certain cases (e.g. if processing state
> should be monitored by more than one client, or it represents some
> form of transaction).
>
> Paul.
>
> [1]
> http://google-guice.googlecode.com/svn/trunk/src/com/google/inject/TypeLiteral.java
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
>
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109