Stateless session bean container-pool-conf and bean removal

[nbirch]

Hi,

Using Jboss 3.0.2 on Linux.

I have an app that is not consistently calling .remove() on its stateless session bean (SSB) remote interfaces. This goes against most sample code I've seen.
Most sample code I've seen gets the SSB home, calls create() on the home, does work using the SSB remote interface object, and then calls remove() on the SSB remote interface object.

Our stateless sessionBean container configuration has the pool MaximumSize set to 100. So, without the .create() to .remove() ratio being 1:1, will the size of the pool get to 100 and stay there? I do not have the strict maximum enforced so will it grow above 100?
During low use periods will the container remove some pooled instances itself?

Thanks,
NBirch

[jonlee]

The pool size will shrink. You can tune the minimumSize as well. At the moment, without a strictMaximumSize, the pool does some strange things but essentially does grow - I understand it is under investigation. For load environments, I would suggest tuning is preferred if not essential. We have a jboss.xml for our EJB deployments but for our applications, we prefer to have better tuning capability on a per component basis rather than a global "one size fits all" policy. YMMV.

[nbirch]

Hi,

Unfortunately it looks like the version of JBoss I'm using (JBoss3.0.2) does not support strictMaximumSize and MinimumSize, but 3.2.1 does. I just cheked the DTDs for each version.

So does this mean that the number of elements in my pool will grow as a result of the bug you mentioned? I am seeing memory growth over time and eventually we get outOfMemory exceptions.

I have gone through our application and added remove() calls at the end of all stateless session bean usage. So as I understand it, this will not immediately remove an instance from the pool, but it will remove the EJBObject. If we neglect to call .remove() on the remote interface we would have a memory leak due to old EJBObjects lying around. Is that correct?

Thanks
NBirch