tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cristian Botiza <Cristian.Bot...@endava.com>
Subject RE: Question on @EJB and JNDI lookup
Date Thu, 06 May 2010 08:04:03 GMT
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
<Cristian.Botiza@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.

Mime
View raw message