Ah Yes I remember reading that thread now :). Thanks
On Tue, Jul 22, 2008 at 10:28 PM, David Blevins <[EMAIL PROTECTED]> wrote: > > 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 > >
