Hi Jan,
you should have a look at this thread first:
http://www.java.net/forum/topic/glassfish/glassfish/asynchronous-configuration
I think it is still valid.
Today I tried to improve the performance of one of our components at
work by using @Asynchronous. My first impression is that the overhead of
overhanding control to another thread pays only of if the actual work
takes some time. In my case I got the impression that overhanding the
control to another thread took the same time as the computation it-self.
I played a little bit with the number of parallel invocations. Executing
the same method more then ten times slowed down the execution.
Furthermore I wasn't able to queue more then 250 parallel invocations
without getting exception. So if you are going to use @Asynchronous you
should take this into consideration.
Bye,
Oliver
On 02.10.2012 18:13, Jan Algermissen wrote:
> 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
>