You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Cristian Botiza <Cr...@endava.com> on 2010/05/05 10:54:33 UTC
Question on @EJB and JNDI lookup
Hi OpenEJB community
I initially asked this on Geronimo forums, they sent me here
I have some CXF service classes and I was using explicit JNDI lookup to retrive some stateless EJB instancess that the web services classes would call.
I did the lookup only once, in a static{} block in the service classes.
All was fine, but at some point after some heavy load on the server I got a nasty exception
java.lang.IllegalStateException: Bean 'Services-1.0.jar/SystemStatusAware' has been undeployed.
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.getDeploymentInfo(BaseEjbProxyHandler.java:557)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:212)
at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
I assumed this was the 'expected' behavior, i.e. OpenEJB trying to free up the resources and 'invalidating' the EJB proxy.
I thought I could get around this using plain servlets and @EJB annotation. However, I fear the same issue may occur as I think @EJB transaltes to a single JNDI lookup and I won't get a fresh bean instance at each call into the servlet.
Should I use an explicit JNDI lookup and only cache the InitialContext?
I'm using Geronimo 2.1.4 and the OpenEJB embedded in it.
Many thanks
________________________________
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Any opinions expressed are mine and do not necessarily represent the opinions of the Company. Emails are susceptible to interference. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited and may be unlawful. If you have received this message in error, do not open any attachments but please notify the EndavaIT Service Desk on (+44 (0)870 423 0187), and delete this message from your system. The sender accepts no responsibility for information, errors or omissions in this email, or for its use or misuse, or for any act committed or omitted in connection with this communication. If in doubt, please verify the authenticity of the contents with the sender. Please rely on your own virus checkers as no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
Endava Limited is a company registered in England under company number 5722669 whose registered office is at 125 Old Broad Street, London, EC2N 1AR, United Kingdom. Endava Limited is the Endava group holding company and does not provide any services to clients. Each of Endava Limited and its subsidiaries is a separate legal entity and has no liability for another such entity's acts or omissions. Please refer to the “Legal” section on our website for a list of legal entities.
RE: Question on @EJB and JNDI lookup
Posted by Cristian Botiza <Cr...@endava.com>.
I was fearing you will say 'However, presumably the
JNDI lookup will fail if your bean becomes undeployed as has been in this
case' ...:)
I got away by recoding my CXF services to do lokkup calls at each web service call, the impact on the code/JUnit base being minimal this way.
Unfortunately this issue occurred only once after some heavy load (hundreds of sequential calls) on the web services followed by some period of inactivity and then it broke at the first new call after the inactivity period. EJBs were cached in a singleton class (not a singleton EJB unfortunately as we're bound to EJB 3.0)
I didn't change the pool sizes or anything - used only what Geronimo gave us.
The real trouble was that after that point no web service call was possible without restarting the application.
Regards
Cristian
________________________________________
From: Jonathan Gallimore [jonathan.gallimore@gmail.com]
Sent: 06 May 2010 00:05
To: users@openejb.apache.org
Subject: Re: Question on @EJB and JNDI lookup
Hi Cristian,
This is an interesting one - using @EJB on your servlet should be fine. As
you point out the injection will happen when the servlet is initialized
rather than on each call. Doing a JNDI lookup manually will guarantee the
lookup happens each time your servlet is called. However, presumably the
JNDI lookup will fail if your bean becomes undeployed as has been in this
case.
Is this easy to reproduce, if so, are you able to let us have a small test
case so we can see what's going on and debug it?
Regards
Jon
On Wed, May 5, 2010 at 9:54 AM, Cristian Botiza
<Cr...@endava.com>wrote:
> Hi OpenEJB community
>
> I initially asked this on Geronimo forums, they sent me here
>
> I have some CXF service classes and I was using explicit JNDI lookup to
> retrive some stateless EJB instancess that the web services classes would
> call.
> I did the lookup only once, in a static{} block in the service classes.
> All was fine, but at some point after some heavy load on the server I got a
> nasty exception
>
> java.lang.IllegalStateException: Bean 'Services-1.0.jar/SystemStatusAware'
> has been undeployed.
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.getDeploymentInfo(BaseEjbProxyHandler.java:557)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:212)
> at
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
>
> I assumed this was the 'expected' behavior, i.e. OpenEJB trying to free up
> the resources and 'invalidating' the EJB proxy.
>
> I thought I could get around this using plain servlets and @EJB annotation.
> However, I fear the same issue may occur as I think @EJB transaltes to a
> single JNDI lookup and I won't get a fresh bean instance at each call into
> the servlet.
> Should I use an explicit JNDI lookup and only cache the InitialContext?
>
> I'm using Geronimo 2.1.4 and the OpenEJB embedded in it.
>
> Many thanks
>
> ________________________________
> The information in this email is confidential and may be legally
> privileged. It is intended solely for the addressee. Any opinions expressed
> are mine and do not necessarily represent the opinions of the Company.
> Emails are susceptible to interference. If you are not the intended
> recipient, any disclosure, copying, distribution or any action taken or
> omitted to be taken in reliance on it, is strictly prohibited and may be
> unlawful. If you have received this message in error, do not open any
> attachments but please notify the EndavaIT Service Desk on (+44 (0)870 423
> 0187), and delete this message from your system. The sender accepts no
> responsibility for information, errors or omissions in this email, or for
> its use or misuse, or for any act committed or omitted in connection with
> this communication. If in doubt, please verify the authenticity of the
> contents with the sender. Please rely on your own virus checkers as no
> responsibility is taken by the sender for any damage rising out of any bug
> or virus infection.
>
> Endava Limited is a company registered in England under company number
> 5722669 whose registered office is at 125 Old Broad Street, London, EC2N
> 1AR, United Kingdom. Endava Limited is the Endava group holding company and
> does not provide any services to clients. Each of Endava Limited and its
> subsidiaries is a separate legal entity and has no liability for another
> such entity's acts or omissions. Please refer to the “Legal” section on our
> website for a list of legal entities.
>
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Any opinions expressed are mine and do not necessarily represent the opinions of the Company. Emails are susceptible to interference. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited and may be unlawful. If you have received this message in error, do not open any attachments but please notify the EndavaIT Service Desk on (+44 (0)870 423 0187), and delete this message from your system. The sender accepts no responsibility for information, errors or omissions in this email, or for its use or misuse, or for any act committed or omitted in connection with this communication. If in doubt, please verify the authenticity of the contents with the sender. Please rely on your own virus checkers as no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
Endava Limited is a company registered in England under company number 5722669 whose registered office is at 125 Old Broad Street, London, EC2N 1AR, United Kingdom. Endava Limited is the Endava group holding company and does not provide any services to clients. Each of Endava Limited and its subsidiaries is a separate legal entity and has no liability for another such entity's acts or omissions. Please refer to the “Legal” section on our website for a list of legal entities.
Re: Question on @EJB and JNDI lookup
Posted by Jonathan Gallimore <jo...@gmail.com>.
Hi Cristian,
This is an interesting one - using @EJB on your servlet should be fine. As
you point out the injection will happen when the servlet is initialized
rather than on each call. Doing a JNDI lookup manually will guarantee the
lookup happens each time your servlet is called. However, presumably the
JNDI lookup will fail if your bean becomes undeployed as has been in this
case.
Is this easy to reproduce, if so, are you able to let us have a small test
case so we can see what's going on and debug it?
Regards
Jon
On Wed, May 5, 2010 at 9:54 AM, Cristian Botiza
<Cr...@endava.com>wrote:
> Hi OpenEJB community
>
> I initially asked this on Geronimo forums, they sent me here
>
> I have some CXF service classes and I was using explicit JNDI lookup to
> retrive some stateless EJB instancess that the web services classes would
> call.
> I did the lookup only once, in a static{} block in the service classes.
> All was fine, but at some point after some heavy load on the server I got a
> nasty exception
>
> java.lang.IllegalStateException: Bean 'Services-1.0.jar/SystemStatusAware'
> has been undeployed.
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.getDeploymentInfo(BaseEjbProxyHandler.java:557)
> at
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:212)
> at
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
>
> I assumed this was the 'expected' behavior, i.e. OpenEJB trying to free up
> the resources and 'invalidating' the EJB proxy.
>
> I thought I could get around this using plain servlets and @EJB annotation.
> However, I fear the same issue may occur as I think @EJB transaltes to a
> single JNDI lookup and I won't get a fresh bean instance at each call into
> the servlet.
> Should I use an explicit JNDI lookup and only cache the InitialContext?
>
> I'm using Geronimo 2.1.4 and the OpenEJB embedded in it.
>
> Many thanks
>
> ________________________________
> The information in this email is confidential and may be legally
> privileged. It is intended solely for the addressee. Any opinions expressed
> are mine and do not necessarily represent the opinions of the Company.
> Emails are susceptible to interference. If you are not the intended
> recipient, any disclosure, copying, distribution or any action taken or
> omitted to be taken in reliance on it, is strictly prohibited and may be
> unlawful. If you have received this message in error, do not open any
> attachments but please notify the EndavaIT Service Desk on (+44 (0)870 423
> 0187), and delete this message from your system. The sender accepts no
> responsibility for information, errors or omissions in this email, or for
> its use or misuse, or for any act committed or omitted in connection with
> this communication. If in doubt, please verify the authenticity of the
> contents with the sender. Please rely on your own virus checkers as no
> responsibility is taken by the sender for any damage rising out of any bug
> or virus infection.
>
> Endava Limited is a company registered in England under company number
> 5722669 whose registered office is at 125 Old Broad Street, London, EC2N
> 1AR, United Kingdom. Endava Limited is the Endava group holding company and
> does not provide any services to clients. Each of Endava Limited and its
> subsidiaries is a separate legal entity and has no liability for another
> such entity's acts or omissions. Please refer to the “Legal” section on our
> website for a list of legal entities.
>
RE: Question on @EJB and JNDI lookup
Posted by Cristian Botiza <Cr...@endava.com>.
Ok, thanks for the valuable info. I didn't undeploye the bean myself
I am using SUN's Java 1.6.0_14 on Windows, the 32 bit version
________________________________________
From: David Blevins [david.blevins@visi.com]
Sent: 06 May 2010 11:49
To: users@openejb.apache.org
Subject: Re: Question on @EJB and JNDI lookup
On May 5, 2010, at 1:54 AM, Cristian Botiza wrote:
> All was fine, but at some point after some heavy load on the server I got a nasty exception
>
> java.lang.IllegalStateException: Bean 'Services-1.0.jar/SystemStatusAware' has been undeployed.
> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.getDeploymentInfo(BaseEjbProxyHandler.java:557)
> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:212)
> at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
>
> I assumed this was the 'expected' behavior, i.e. OpenEJB trying to free up the resources and 'invalidating' the EJB proxy.
Did you undeploy the EJB app? I assume the answer is no, but have to ask as the only other explanation is a very terrible bug in the VM.
In each proxy (i.e. reference to a bean) we use a java.lang.ref.WeakReference to point to the bean itself. If the bean hasn't been undeployed, the VM would be seriously breaking the WeakReference contract by cleaning out the reference when there are still hard references to the bean in the server.
Definitely post your jvm info (version and vendor). If we think this is a vm bug, I can also give you some code to check that the "bean" is still in the system.
-David
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Any opinions expressed are mine and do not necessarily represent the opinions of the Company. Emails are susceptible to interference. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited and may be unlawful. If you have received this message in error, do not open any attachments but please notify the EndavaIT Service Desk on (+44 (0)870 423 0187), and delete this message from your system. The sender accepts no responsibility for information, errors or omissions in this email, or for its use or misuse, or for any act committed or omitted in connection with this communication. If in doubt, please verify the authenticity of the contents with the sender. Please rely on your own virus checkers as no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
Endava Limited is a company registered in England under company number 5722669 whose registered office is at 125 Old Broad Street, London, EC2N 1AR, United Kingdom. Endava Limited is the Endava group holding company and does not provide any services to clients. Each of Endava Limited and its subsidiaries is a separate legal entity and has no liability for another such entity's acts or omissions. Please refer to the “Legal” section on our website for a list of legal entities.
Re: Question on @EJB and JNDI lookup
Posted by David Blevins <da...@visi.com>.
On May 5, 2010, at 1:54 AM, Cristian Botiza wrote:
> All was fine, but at some point after some heavy load on the server I got a nasty exception
>
> java.lang.IllegalStateException: Bean 'Services-1.0.jar/SystemStatusAware' has been undeployed.
> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.getDeploymentInfo(BaseEjbProxyHandler.java:557)
> at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:212)
> at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
>
> I assumed this was the 'expected' behavior, i.e. OpenEJB trying to free up the resources and 'invalidating' the EJB proxy.
Did you undeploy the EJB app? I assume the answer is no, but have to ask as the only other explanation is a very terrible bug in the VM.
In each proxy (i.e. reference to a bean) we use a java.lang.ref.WeakReference to point to the bean itself. If the bean hasn't been undeployed, the VM would be seriously breaking the WeakReference contract by cleaning out the reference when there are still hard references to the bean in the server.
Definitely post your jvm info (version and vendor). If we think this is a vm bug, I can also give you some code to check that the "bean" is still in the system.
-David