[jboss-user] [EJB/JBoss] - Re: serious leak container doesnt call ejb remove() -- urgen
do-not-reply at jboss.com
Tue Apr 29 09:11:46 EDT 2008
The container needs not remove SLSBs. SLSBs are, as the name implies, stateless. Therefore, they can be reused, and the container does exactly that. They are kept in an instance pool and reused when necessary. This is a feature, it allows the container to use an already constructed instance instead of incurring the penalty of class instantiation each time. Therefore, you cannot be sure whether ejbRemove() is going to be called or not, it will only when the instance is actually removed from the pool.
SLSBs do not passivate, either. Passivation is simply not part of a stateless bean lifecycle (they are simply destroyed and recreated).
The pool's size (as configured in standardjboss.xml) is not a hard limit. If more instances are needed, the container will create them as necessary, without limitation. To enforce the limit, you need to set strictMaximumSize to "true" in the container-pool-conf tag of either standardjboss.xml or the application specific jboss.xml. If the pool limit is reached, further requests will keep waiting until an instance is freed. You can specify which amount of time to wait for an instance with the strictTimeout parameter (if not specified, requests will wait basically forever).
There's a KeepAliveMillis property that should indicate how much time to keep unused instances in the container pool, but as far as I know it is not implemented, at least on JBoss AS 4.2.1. You can clean the pool manually by identifying the pool object in jmx-console: under jboss.j2ee search an MBean named as your EJB plus the ",plugin=pool,service=EJB" string (for example, "jndiName=ejb/SampleEJB,plugin=pool,service=EJB") and invoke the clear() method, it just flushes the instance pool. This MBean also provides info about the pool status and size. You can also invoke this method programmatically (by instantiating and using the MBean from anywhere in your code), but this is nasty politics, and things could get hairy if you're clustering your EJBs.
Better to size your pools accordingly, and of course use stateless beans for their intended purpose: non-transactional calls or fast transacting calls. When your SLSB enters a transaction, it is no longer available to service other calls, and another one will be created if needed. So, keep them within transactions for as least as possible. If you're using SLSBs as facades, make them non-transactional (transfer transaction demarcation to inner EJBs).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147500#4147500
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147500
More information about the jboss-user