users@glassfish.java.net

Cost of _at_Asynchronous

From: Jan Algermissen <jan.algermissen_at_nordsc.com>
Date: Tue, 2 Oct 2012 18:13:27 +0200

Hi,

JAX-RS 2.0 [1] comes with a new async feature that makes it possible to hand JAX-RS response creation to another thread, allowing the request handling thread to continue working on requests immediately.

Combined with @Asynchronous this makes for pretty elegant code:


@Stateless
@Path("/")
class EJBResource {
  
  @GET @Asynchronous
  public void longRunningOp(@Suspended AsyncResponse ar) {
    executeLongRunningOp();
    ar.resume("Hello async world!");
  }
}


Now, handing control to a new or pre-created thread does not come for free. And I am wondering what factors to consider in order to estimate whether an async response will improve performance or capacity in a given scenario.

I would assume that thread pool allocations and sizes influence this quite a bit. For example, when I configure large JPA thread pools so that every async JPA-backed response finds a free thread already waiting I'd expect improvements over synchronous response.

Is this the right way to approach this? Or am I completely of track?

Jan


[1] http://www.jcp.org/en/jsr/detail?id=339