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> 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
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>