serious leak container doesnt call ejb remove() -- urgent pl

[aagmon]

hi every body ,
i have a serious problem on a production server,
we have an ejb dealing with DB actions.
now after a few days i noticed in the web console that the create count just keep raising without any call to remove().
and after the thread count goes beyond 500 when i try to login to the web console for instance through jaas (file role based) i get an IO error too many open files ....
whats it got to do with the remove().

here are the bean's lifcycle methods:

public void ejbCreate(){
 getSessionFactory(); --gets hibernate session

 Logger log = Logger.......get log stuff
 }
 public void ejbRemove(){}
 public void ejbActivate(){
 getSessionFactory();
 Logger log = Logger.......get log stuff
 }
 public void ejbPassivate(){
 factory = null;
 log = null;

 }

i just dont know how to address this problem

[tperrigo]

Need a little more information...what kind of EJB is this? In the code you posted, ejbRemove is just an empty method-- it's not doing anything. If it is a stateless session bean, you don't want to put your cleanup code in ejbPassivate.

[aagmon]

thanks for the reply,

as far as i know ejbPassivate is just a phase in the way to remove()...
its a SLSB using hibernate to various DB tasks ,
thats it really.....
just tell me what info do you need

[darranl]

The ejbActivate and ejbPassivate methods are not called for SLSBs, they need to be there but should be left empty.

[mdonato]

Hi all,

I have the same problem.

I'm using jboss-4.0.2 and a lot of StateLess Session Bean.

Using my application a long period of time, the memory leaks and throws an Out Of Memory Exception. And i saw, in web-console that my beans are only created and never removed.

Reading docs and analising configs xml files, i found the max size of pool, and it has 100, and some of my beans become overloaded up to 300-400, wherever.

It means up to max limit. What is wrong? Shoudn't The container remove it ? Should I remove it programaticaly??

What do i have to do ??? It makes me crazy!!!!

On other container like websphere it doesn't happens!!!!

Someone can helpe me ???

[domyalex]

Hi; I have the exact same problem.
I'm using 4.2.2 GA and basically a new stateless bean gets created with every new request.
Do I need to call any particular clean up method?

Regards

[mikkus]

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).

[bondchan921]

Emir, greate explaination ! I have the same problem exactly, but I'm using SFSB

from jbm-console, just like your list above, check the parameter values, shows 195 instances have been created, and after the time-out, none in the cache,  but ejbRemove() never get called.

[bondchan921]

get the answer now....

when SFSB in passivated state, the ejbRemove never get called

https://community.jboss.org/message/294999#294999