@Oliver
What do you mean by "Executing the same method more then ten times slowed
down the execution." ?
br Jakub
2012/10/3 Oliver Fischer <mailsink_at_swe-blog.net>
> Hi Jan,
>
> you should have a look at this thread first:
> http://www.java.net/forum/**topic/glassfish/glassfish/**
> asynchronous-configuration<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<http://www.jcp.org/en/jsr/detail?id=339>
>>
>>