On Jul 22, 2008, at 5:40 AM, Manu George wrote:
I had a look at this and am facing a certain behaviour that is
puzzling me. I create an EJB and from a client make a 1000 parallel
invocations. I set the poolSize as say 10 for the stateless container
but still all the 1000 invocations use only a single instance.
The ThreadPoolExecutor in ServicePool seems to be deciding how many
threads are executing in parallel and most of the time the execution
is happening serially. At much higher loads more instances are getting
created but that is decided by how many threads are being created by
the ThreadPoolExecutor. So the timeout variable which i worked back in
seems to be not to be getting used most of the time.
It's actually getting decided by the client. See this description
from the "Remote client performance" thread.
On Jul 13, 2008, at 5:41 PM, David Blevins wrote:
I also made it so the client can have at most one open connection
per server URL and all requests file through it.
For the record you can actually get more connections per client by
slightly appending to your server url as so:
ejbd://localhost:4201/a
ejbd://localhost:4201/b
Everything after the "/" is currently ignored, but will allow you to
get another connection to the same server if you think you really
need it. I actually saw pretty great performance with just one
connection shared among 10 client threads, but maybe you want a
second connection open for very long running requests as to not
block up the shorter requests.
I'd say the best way to test the pooling is to have a testcase that
uses the LocalInitialContextFactory. Then you can test as many
threads as you need and have the container code more isolated than
with including the client/server code as well. Should also allow you
to keep the test case in the openejb-core package.
-David
