Nick Stuart wrote:
> So are you thinking that this is something that will actually be
> implemented on the server side of things?
I think it just makes more sense to be scalable when services are
clients too, but in general services that are clients or stand alone
clients can benefit from an async API e.g. one use case is when a client
wants to make multiple independent requests but does not want to perform
and wait for such requests in sequence.
> Depending on the they type of
> client, or the type of parameter passed in? (ie Future<String>)
Yes.
> 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.
I can understand, which is why the API should be doing it for you.
> 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.
>
OK!
Paul.
> 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