Thanks Jakub. Sorry but I need a little clarification. My general rule of
thumb is to keep request less than 500 msecs if possible. The polling GET
allows the client to make a quick call to see if the request is still being
processed or is ready (in which case it gets the see other). I'm not sure
how AsyncResponse is helpful here since the client will stay connected to
the server until the response is resumed. Is that right? For example (error
handling is removed for brevity):
@POST
public Response submitLongOperation( ... ) {
String jobId = jobServer.submit( "long operation code" ); // returns
immediately
URI location = addJobIdToPath( jobId );
return Response.status( Response.Status.ACCEPTED ).location( location
).build();
}
@GET
@Path( "{jobId}" )
public Response getStatus( @Param jobId, @Context UriInfo uriInfo ) {
if ( !jobServer.isDone( jobId ) )
return Response.ok(); // still processing
URI resultLocation = uriInfo.getAbsolutePathBuilder().path( "result"
).build();
return Response.seeOther( resultLocation );
}
Then finally:
@GET
@Path( "{jobId}/result" )
public Object getResult( @Param jobId ) {
return jobServer.getResult( jobId ); // returns immediately and removes
the result from redis
}
In this case JobServer is distributed. So you can route the client request
to any one of multiple server instances and everything will work as
expected. As a result I have scaled out (I can add more rest services
without side-effect) and all my requests are short-lived (less than a few
msecs).
How would I use AsyncResponse here without making the calls long lived or
introducing statefullness? Or should I be doing something else? I am no
expert on REST or Jersey but this approach seemed to be the most sane. So I
am eager to find a better approach or see where Jersey 2.0 might help me.
Unless I'm misunderstanding, AsyncResponse would really only help me scale
up but not help me scale out?
Thanks for your patience as I try to grok all of this.