Jan and Crew
besides the maximum number of threads per container another *important consideration* is thread completion wait time
I had a situation where I was making a SSL connection to a server here thru a Proxy on opposite side of planet
so to trap worker threads exceeding amount of time i
started a timer
Create worker thread
wait for the worker thread run() method to be invoked
main thread asks
if actual_elapsed_time > user_specified_elapsed_time
stop worker thread
return to main thread
Takk,
Martin Gainty
______________________________________________
Note de déni et de confidentialité
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Subject: Re: Cost of @Asynchronous
> From: jan.algermissen_at_nordsc.com
> Date: Wed, 3 Oct 2012 18:31:47 +0200
> To: users_at_glassfish.java.net
>
> Oliver,
>
> On Oct 3, 2012, at 2:01 AM, Oliver Fischer wrote:
>
> > 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.
>
> thanks a lot - that resonates with my assumptions.
>
> Jan
>
>
> >
> > 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
> >>
>