On Jun 2, 2005, at 8:59 AM, Jeremy Boynes wrote:
Dain Sundstrom wrote:
On Jun 2, 2005, at 6:45 AM, Jeremy Boynes wrote:
The CORBA implementation consumes 9 threads from the pool which
with default settings can cause the EJB transport to hang.
What is it using these threads for? Is there some bug which
prevents them being returned to the pool, or are these permanent
threads it needs and if so shouldn't it be allocating them directly?
It is pretty simple. The each CSS Bean deployed acquires 2
threads, one for the name service orb and one to start the css
orb, and the CORBABean consumes one thread. We have 4 CSS beans
deployed and one CORBABean giving us a total thread usage of 9.
You can see the thread dump below.
Should all of these come from the same thread pool as the non-CORBA
transport?
I believe that is a configuration/service organization discussion we
should have once certification is complete. The good thing is we
have the thread creation externalized so we can choose how we want to
handle this later.
How does this scale, both with the number of EJBs deployed and the
number of inbound requests?
You have two threads per CSS bean. I believe that a css bean is a
corba protocol configuration and we have 4 in the configuration you
are looking at. This is not a per EJB allocation. As for scaling
with inbound requests, I have no idea. I don't think this thread is
related to the inbound requests at all. I believe it is simply an
internal orb management thread used to control shutdown of the orb.
This is just a guess, Alan it the expert.
With the current setup, what criteria should a user use to size the
pool?
Since we have no reasonable way for a user to configure our server,
we just need to pick a good (large) default. We can deal with
helping our users tune the server post certification, and after we
get a way for users to configure the system.
How do we set it up so that if the pool is undersized then we get
an error rather than just have the transport hang?
I'm looking into this one. The default for the current thread pool
is to have the requesting thread run the task, which bad for our case
since the requesting thread is the socket acceptor. I think we
should instead set abortWhenBlocked on the thread pool so we get an
exception. It would be nice if there were a wait 10sec option to
deal with floods, but I don't see any options for that.
-dain
