On May 19, 2008, at 9:31 AM, Nick Stuart wrote:
> Having the server still accept the request and just return
> immediately, and then do the processing, makes more sense though.
>
HTTP has status code 202 for this:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3
You can include a Location header with a URI that can be polled for
status.
Marc.
>
> 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
>
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.