JBossDeveloper

We increased the thread pool size and everything completed, just like you said.

This is a bit confusing for me now. Is this the expected behavior (methods never get invoked under heavy load)? Shouldn't it just be distributed over available threads?

 

Aside from this, are there any negative side effects caused by increasing the maximum number of threads in the pool? Is there a link where I can get some more info on that, I'd like to better understand all this before deciding that it's OK for me to fix this in this way (for an example, what exactly is this pool used for?)?

There is some documentation here that mentions the EJB3 thread-pools "This is used to configure the thread pools used by async, timer and remote invocations".

I didn't actually need to set max-threads so high, I just wanted to point out that it should be higher than 10 for running the test case.

Looking at the test case, for every servlet request received, a series of asynchronous beans are invoked, each in their own thread.  To reduce the number of threads consumed, the application could change to have only the first bean invocation be asynchronous.

As to the implied question posed by the test case, if a set of asynchronous beans are invoked from the same EJB container, could they be optimized to execute in the same asynchronous thread (to consume fewer resources)?  I don't have the answer but think its an interesting question.

Scott

As to the implied question posed by the test case, if a set of asynchronous beans are invoked from the same EJB container, could they be optimized to execute in the same asynchronous thread (to consume fewer resources)?  I don't have the answer but think its an interesting question.

A few examples to consider:

If the top level invoked bean, wants to run a request in parallel, over eight CPUs, it would probably invoke eight async beans (consuming eight threads + one for the top level bean).  Each call to the top level bean, will consume nine threads (for the duration of the invocation).

Initially, this application is only used by a small number of users, but later, the user base grows and rather than requiring nine threads per user requests, we switch to using two threads (one for the top level request and one for the async bean(s)).

Rather than changing application code to arrange for multiple async beans to share the same thread, a configuration change is made instead.  Sometimes its easier to change configuration than thousands of lines of application code to try a change like this.

Is this idea of running mutiple async beans in the same background thread specification legal?  I'm not sure, haven't looked at that .  Anyway, just thought I would share this idea to see if there is interest in discussion a possible configuration option that might help (as an alternative to changing the app code).

Thoughts?

In my very humble opinion:

If the top level invoked bean, wants to run a request in parallel, over eight CPUs, it would probably invoke eight async beans (consuming eight threads + one for the top level bean).  Each call to the top level bean, will consume nine threads (for the duration of the invocation).

 

Initially, this application is only used by a small number of users, but later, the user base grows and rather than requiring nine threads per user requests, we switch to using two threads (one for the top level request and one for the async bean(s)).

 

Rather than changing application code to arrange for multiple async beans to share the same thread, a configuration change is made instead.  Sometimes its easier to change configuration than thousands of lines of application code to try a change like this.

I guess switching to one thread (and basically to sequential execution) might help preventing exhausting the resources, but it pretty much kills the whole point of asynchronous parallel execution of multiple tasks - you lose performance drastically. In that case, if it were up to me, I'd start thinking of scaling up my server.

It might not be a bad thing, maybe during development before you're sure whether you need parallel execution or not or as a temporary solution.

PS:

On the side note and referring to the blocking issue we've managed to reproduce, I still think that no use case should be allowed to block the execution, the cause being the application server logic (filled task queues, or whatever may be the end cause).

Best regards,

Nenad