> > > A thread dump and the OpenEJB version would be great. Stateless session > beans are pooled, so it could be there are no more instances in the pool and > calls are waiting for new instances. Depending on the OpenEJB version, the > timeout for such situations is configurable. > > -David > > Okay I feel bad for not checking that before asking over here. Following that last extremely low configuration I used in the configuration file(when we found that bug for passivation) I hadn't changed the configuration back to normal. Here it is.
<Container id="My Stateless Container" type="*STATELESS*"> *TimeOut 0* *PoolSize 1* *StrictPooling true* </Container> So to conclude, this means, due to the *PoolSize 1 *and a *TimeOut 0*, 1. The bean is made unavailable by the container due to the non application exception. 2. Since the exception cascades, two stateless beans(of different types) are forwarded to removal. 3. Since they are not removed by the container yet, new calls are kept waiting till a new instance is ready. The specs say the container cleans up, hence the PreDestroy will not be called. When exactly will these beans, once queued for removal, be removed? Thanks a lot for the help. The following configuration now works. TimeOut *10000* PoolSize *100* StrictPooling *false* -- Akila...
