tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravindranath Akila <>
Subject Re: Non-Application Exception in Session Bean Cascades Destruction of Other Session Beans?
Date Sat, 19 Jun 2010 06:37:17 GMT
> 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*


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
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*


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message