You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by David Blevins <da...@visi.com> on 2010/06/18 03:56:52 UTC
Re: Non-Application Exception in Session Bean Cascades Destruction of Other Session Beans?
On Jun 17, 2010, at 1:33 PM, Ravindranath Akila wrote:
> Hello,
> Below I have pasted a non-application exception. (This is an exception
> which occured due to an error in persisting an entity).
>
> The problem I am facing is that,
>
> The container will as expected, destroy the session bean in which the
> non-application exception occurred.
> This session bean however, is a class variable injected into ANOTHER
> session bean.
> This means, its destruction will cause the wrapping(enclosing) session
> bean to be unstable too.
> However, does the container destroy this enclosing session bean too? Is
> this scenario handled?
>
> What happens to me is that I think a new lookup just leaves the thread
> hanging.
>
> Am I doing something wrong here? What happens to the enclosing session
> bean? Am I to expect "Reference is Invalid" message?
>
> Thanks in advance.
>
>
> P.S.
>
> From the spec ejb-3_1-fr section 14.2.2
>
> "• Unless the bean is a Singleton bean, no other method will be invoked on
> an instance that threw
> a non-application exception.
>
> This means that unless the bean is a Singleton the Bean Provider does not
> have to perform any cleanup
> actions before throwing a non-application exception. It is the container
> that is responsible for the
> cleanup."
It definitely would destroy the "enclosing" bean if that bean did not catch the exception.
-David
Re: Non-Application Exception in Session Bean Cascades Destruction of
Other Session Beans?
Posted by Ravindranath Akila <ra...@gmail.com>.
****dump*.
It should be **3 rounds of calls*. 4th was meant to be the working scenario
in which no non application exception is thrown. This scenario actually does
not trigger this problem.
Akila...
Re: Non-Application Exception in Session Bean Cascades Destruction of
Other Session Beans?
Posted by Ravindranath Akila <ra...@gmail.com>.
>
>
> 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...
Re: Non-Application Exception in Session Bean Cascades Destruction of Other Session Beans?
Posted by David Blevins <da...@visi.com>.
On Jun 18, 2010, at 2:59 AM, Ravindranath Akila wrote:
> I still cannot figure out what is happening.
> I will explain with additional information.
>
> I have a *singleton *called *DBLocal *with *@Startup* scope.
>
> DBLocal looks up *HumanCRUDHumanLocal*(*stateless* SB) with a context look
> up(not injection).
>
> The interceptor for DBLocal reports that an instance is returned(and it is
> not null either).
>
> HumanCRUDHumanLocal has a class variable injected called *
> UHumansIdentityLocal*(*stateless *SB).
>
>
> Now, explaining the scenario in 4 rounds of calls
> 1. DBLocal looks up(context) HumanCRUDHumanLocal. HumanCRUDHumanLocal calls
> a method in UHumansIdentityLocal. UHumansIdentityLocal's method throws a *non
> application exception*. This is caught and reported in an interceptor for
> HumanCRUDHumanLocal.
>
>
> http-8080-*1*|2010-06-18 15:14:30,031|DEBUG:141>Timing:public
> ai.ilikeplaces.logic.crud.HumanCRUDHumanLocal
> ai.ilikeplaces.logic.crud.DB.getHumanCRUDHumanLocal():done. [Time
> Taken:0]//LOOKUP//*Interceptor for DBLocal*
>
> http-8080-*1*|2010-06-18 15:14:30,265|DEBUG:141>Timing:public
> ai.ilikeplaces.util.Return
> ai.ilikeplaces.logic.crud.HumanCRUDHuman.doUHumansPublicURL(ai.ilikeplaces.util.RefObj,java.lang.String):done.
> [Time Taken:203]//METHOD RETURN//*Interceptor for **HumanCRUDHuman*
>
>
> 2. DBLocal looks up(context) HumanCRUDHumanLocal. However, there onwards,
> the log indicates no calling of the interceptor for HumanCRUDHuman.
>
> http-8080-*1*|2010-06-18 15:14:52,093|DEBUG:141>Timing:public
> ai.ilikeplaces.logic.crud.HumanCRUDHumanLocal
> ai.ilikeplaces.logic.crud.DB.getHumanCRUDHumanLocal():done. [Time
> Taken:0]//LOOKUP//*Interceptor for DBLocal*
>
> 3. DBLocal looks up(context) HumanCRUDHumanLocal on a page refresh. New
> thread. Still no indication of HumanCRUDHumanLocal methods being called.
>
> http-8080-*2*|2010-06-18 15:15:01,593|DEBUG:141>Timing:public
> ai.ilikeplaces.logic.crud.HumanCRUDHumanLocal
> ai.ilikeplaces.logic.crud.DB.getHumanCRUDHumanLocal():done. [Time
> Taken:0]//LOOKUP//*Interceptor for DBLocal*
>
> *The returned **HumanCRUDHumanLocal cannot be null because DBLocal
> checks*for this before returning.
> * This means an instance of HumanCRUDHumanLocal is being returned but any
> calls on it leaves the thread hanging.**
> *
> Any advice would greatly help me. If you need me to attach the sources, I
> will do so. Also, if you need a thread dumb immediately after the above
> calls, I will attach.
>
> To summarize, if a Singleton A, looks up a stateless B, which contains a
> class variable stateless C, and C throws a non application exception,
> further look ups by A on B, returns an instance but leaves the method call
> threads hanging. Am I doing something wrong in coding here?
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
Re: Non-Application Exception in Session Bean Cascades Destruction of
Other Session Beans?
Posted by Ravindranath Akila <ra...@gmail.com>.
I still cannot figure out what is happening.
I will explain with additional information.
I have a *singleton *called *DBLocal *with *@Startup* scope.
DBLocal looks up *HumanCRUDHumanLocal*(*stateless* SB) with a context look
up(not injection).
The interceptor for DBLocal reports that an instance is returned(and it is
not null either).
HumanCRUDHumanLocal has a class variable injected called *
UHumansIdentityLocal*(*stateless *SB).
Now, explaining the scenario in 4 rounds of calls
1. DBLocal looks up(context) HumanCRUDHumanLocal. HumanCRUDHumanLocal calls
a method in UHumansIdentityLocal. UHumansIdentityLocal's method throws a *non
application exception*. This is caught and reported in an interceptor for
HumanCRUDHumanLocal.
http-8080-*1*|2010-06-18 15:14:30,031|DEBUG:141>Timing:public
ai.ilikeplaces.logic.crud.HumanCRUDHumanLocal
ai.ilikeplaces.logic.crud.DB.getHumanCRUDHumanLocal():done. [Time
Taken:0]//LOOKUP//*Interceptor for DBLocal*
http-8080-*1*|2010-06-18 15:14:30,265|DEBUG:141>Timing:public
ai.ilikeplaces.util.Return
ai.ilikeplaces.logic.crud.HumanCRUDHuman.doUHumansPublicURL(ai.ilikeplaces.util.RefObj,java.lang.String):done.
[Time Taken:203]//METHOD RETURN//*Interceptor for **HumanCRUDHuman*
2. DBLocal looks up(context) HumanCRUDHumanLocal. However, there onwards,
the log indicates no calling of the interceptor for HumanCRUDHuman.
http-8080-*1*|2010-06-18 15:14:52,093|DEBUG:141>Timing:public
ai.ilikeplaces.logic.crud.HumanCRUDHumanLocal
ai.ilikeplaces.logic.crud.DB.getHumanCRUDHumanLocal():done. [Time
Taken:0]//LOOKUP//*Interceptor for DBLocal*
3. DBLocal looks up(context) HumanCRUDHumanLocal on a page refresh. New
thread. Still no indication of HumanCRUDHumanLocal methods being called.
http-8080-*2*|2010-06-18 15:15:01,593|DEBUG:141>Timing:public
ai.ilikeplaces.logic.crud.HumanCRUDHumanLocal
ai.ilikeplaces.logic.crud.DB.getHumanCRUDHumanLocal():done. [Time
Taken:0]//LOOKUP//*Interceptor for DBLocal*
*The returned **HumanCRUDHumanLocal cannot be null because DBLocal
checks*for this before returning.
* This means an instance of HumanCRUDHumanLocal is being returned but any
calls on it leaves the thread hanging.**
*
Any advice would greatly help me. If you need me to attach the sources, I
will do so. Also, if you need a thread dumb immediately after the above
calls, I will attach.
To summarize, if a Singleton A, looks up a stateless B, which contains a
class variable stateless C, and C throws a non application exception,
further look ups by A on B, returns an instance but leaves the method call
threads hanging. Am I doing something wrong in coding here?
Thanks a lot.
Re: Non-Application Exception in Session Bean Cascades Destruction of
Other Session Beans?
Posted by Ravindranath Akila <ra...@gmail.com>.
Thank you very much. Now I have to see why actually further calls hang.
Afaik new lookups on this outer bean does not fetch a new instance OR leaves
the thread hanging due to some problem of my own app. I'll check and see.
Probably something I am overlooking. Thanks again.
On Fri, Jun 18, 2010 at 7:26 AM, David Blevins <da...@visi.com>wrote:
>
> On Jun 17, 2010, at 1:33 PM, Ravindranath Akila wrote:
>
> > Hello,
> > Below I have pasted a non-application exception. (This is an exception
> > which occured due to an error in persisting an entity).
> >
> > The problem I am facing is that,
> >
> > The container will as expected, destroy the session bean in which the
> > non-application exception occurred.
> > This session bean however, is a class variable injected into ANOTHER
> > session bean.
> > This means, its destruction will cause the wrapping(enclosing) session
> > bean to be unstable too.
> > However, does the container destroy this enclosing session bean too? Is
> > this scenario handled?
> >
> > What happens to me is that I think a new lookup just leaves the thread
> > hanging.
> >
> > Am I doing something wrong here? What happens to the enclosing session
> > bean? Am I to expect "Reference is Invalid" message?
> >
> > Thanks in advance.
> >
> >
> > P.S.
> >
> > From the spec ejb-3_1-fr section 14.2.2
> >
> > "• Unless the bean is a Singleton bean, no other method will be invoked
> on
> > an instance that threw
> > a non-application exception.
> >
> > This means that unless the bean is a Singleton the Bean Provider does not
> > have to perform any cleanup
> > actions before throwing a non-application exception. It is the container
> > that is responsible for the
> > cleanup."
>
> It definitely would destroy the "enclosing" bean if that bean did not catch
> the exception.
>
>
> -David
>
> --
Cheers!
Akila...