You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2006/02/11 02:03:10 UTC
Strange IllegalAccessError w/FastClassByCGLIB class
Anyone have a clue why this would be happening?
I see these exceptions when running concurrency tests; and once this
occurs the application is blown and I have to restart G to recover.
<snip>
17:00:16,689 WARN [StatelessInstanceFactory] Unexpected error
removing Stateless instance
java.lang.IllegalAccessError: tried to access class
org.springframework.ejb.support.AbstractEnterpriseBean from class
com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewServiceBean$$FastClassByCGLIB$$e322b03a
at com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewServiceBean$$FastClassByCGLIB$$e322b03a.invoke(<generated>)
at org.openejb.dispatch.AbstractMethodOperation.invoke(AbstractMethodOperation.java:90)
at org.openejb.slsb.RemoveMethod.execute(RemoveMethod.java:69)
at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72)
at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56)
at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81)
at org.openejb.slsb.StatelessInstanceContext.ejbRemove(StatelessInstanceContext.java:176)
at org.openejb.slsb.StatelessInstanceFactory.destroyInstance(StatelessInstanceFactory.java:90)
at org.openejb.util.SoftLimitedInstancePool.release(SoftLimitedInstancePool.java:95)
at org.openejb.slsb.StatelessInstanceContext.exit(StatelessInstanceContext.java:116)
at org.apache.geronimo.transaction.context.AbstractTransactionContext.endInvocation(AbstractTransactionContext.java:95)
at org.openejb.slsb.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:105)
at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119)
at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80)
at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82)
at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:129)
at org.openejb.proxy.SessionEJBLocalObject$$EnhancerByCGLIB$$774ce77e.getActiveMerchantACH(<generated>)
at com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean.authorize(POSCheckServiceBean.java:219)
at com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean$$FastClassByCGLIB$$ac29a8c5.invoke(<generated>)
at org.openejb.dispatch.AbstractMethodOperation.invoke(AbstractMethodOperation.java:90)
at org.openejb.slsb.BusinessMethod.execute(BusinessMethod.java:67)
at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72)
at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56)
at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81)
at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119)
at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80)
at org.openejb.slsb.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:98)
at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:140)
at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80)
at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82)
at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
at org.openejb.server.ejbd.EjbRequestHandler.invoke(EjbRequestHandler.java:297)
at org.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(EjbRequestHandler.java:325)
at org.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHandler.java:196)
at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:150)
at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:87)
at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$$d379d2ff.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at org.activeio.xnet.ServerService$$EnhancerByCGLIB$$944b9c52.service(<generated>)
at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67)
at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90)
at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:138)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Thread.java:552)
</snip>
--jason
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Dain Sundstrom <da...@iq80.com>.
Jason, can you try adding an ejbRemove method directly to the class
and see if the problem goes away?
-dain
On Feb 13, 2006, at 4:56 PM, Aaron Mulder wrote:
> It may be the inheritance causing problems rather than the CL, as
> well. You know, maybe we try calling ejbRemove on your bean class
> even though it's declared on the superclass or something. If the CL
> manipulations don't work out, we can follow that path.
>
> As far as the hidden classes, we unfortunately seem to have Spring
> (and I guess Antlr?) on the Server classpath (I think something
> related to clustering, which I'm hoping we can extract). If you load
> that version of Spring, it can't see your bean classes because they're
> in a child class loader. With the hidden classes filter, you're
> saying that any classes beginning with those substrings shouldn't be
> loaded from the parent class loader, so they'll always be loaded from
> the version in your application, and therefore the Spring classes will
> be able to see your bean classes.
>
> Aaron
>
> On 2/13/06, Jason Dillon <ja...@planet57.com> wrote:
>> MerchantViewServiceBean does not have its own ejbRemote(), it
>> picks it
>> up from AbstractStatelessSessionBean (from app), which picks it up
>> from AbstractStatelessSessionBean (from spring).
>>
>> Could be a CL problem... the application is using Spring 1.1.4, which
>> is included in the EAR.
>>
>> In my plan I had to add this to even get the application to init:
>>
>> <hidden-classes><filter>org.springframework</filter></hidden-classes>
>> <hidden-classes><filter>antlr</filter></hidden-classes>
>>
>> I don't really understand what this does either.
>>
>> I will try again w/o the spring jars in the ear and see how that
>> fairs... though I don't really like to have to be put into this
>> situation, where I have to use jars outside of the ear. I personally
>> prefer that in theory, but in practice, the more separate jars that I
>> have to give to QA/Ops, the more chances of them *ucking it up.
>>
>> Anyways, I'd imagine there are a many apps out there that will
>> include
>> jars in their ear for deployment. G should really do the right thing
>> with them... regardless of which is right from a theoretical
>> perspective or not.
>>
>> --jason
>>
>>
>> On 2/13/06, Dain Sundstrom <da...@iq80.com> wrote:
>>> On Feb 13, 2006, at 4:43 AM, Aaron Mulder wrote:
>>>
>>>> On 2/13/06, Jason Dillon <ja...@planet57.com> wrote:
>>>>> I will look at it more... I'm not familiar with the proxy gen
>>>>> in G
>>>>> yet... but a race condition sounds likely since this problem only
>>>>> shows up in multithreaded concurrency test.
>>>>
>>>> I'm not convinced it's a proxy error. I mean, clearly *something*
>>>> happened while calling the remove method, but the message is pretty
>>>> vague -- could be a classloader problem, could be something
>>>> wrong with
>>>> the session bean lifecycle, could be something wrong with the
>>>> test...
>>>> I'm hoping that if we look for where that message is generated
>>>> it'll
>>>> suggest what might be going wrong.
>>>
>>> This is not a proxy error at all. This is caused when calling
>>> FastClass.invoke which is a faster version of reflection. IIRC this
>>> error normally means that the calling code does not have access to
>>> the target method. FWIU, regardless of using reflection or
>>> generated
>>> byte code, the VM will prevent a caller from accessing a method it
>>> would not normally have access to via normal Java code. If the
>>> method is private and you attempt to use reflection to invoke it,
>>> the
>>> VM will throw an IllegalAccessError. This enforcement code gets
>>> weird when you attempt to call across class loaders.
>>>
>>> Anyway, lets start with the basics. Can you post the
>>> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewS
>>> ervi
>>> ceBean.ejbRemove () code?
>>>
>>> BTW, I rewrote this code in OpenEJB head to use plain old reflection
>>> (long story), so it shouldn't appear there. I am curious if you can
>>> reproduce the problem using reflection. Regardless, this is a
>>> problem we need to fix, since we use AbstractMethodOperation all
>>> over.
>>>
>>> -dain
>>>
>>
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
It may be the inheritance causing problems rather than the CL, as
well. You know, maybe we try calling ejbRemove on your bean class
even though it's declared on the superclass or something. If the CL
manipulations don't work out, we can follow that path.
As far as the hidden classes, we unfortunately seem to have Spring
(and I guess Antlr?) on the Server classpath (I think something
related to clustering, which I'm hoping we can extract). If you load
that version of Spring, it can't see your bean classes because they're
in a child class loader. With the hidden classes filter, you're
saying that any classes beginning with those substrings shouldn't be
loaded from the parent class loader, so they'll always be loaded from
the version in your application, and therefore the Spring classes will
be able to see your bean classes.
Aaron
On 2/13/06, Jason Dillon <ja...@planet57.com> wrote:
> MerchantViewServiceBean does not have its own ejbRemote(), it picks it
> up from AbstractStatelessSessionBean (from app), which picks it up
> from AbstractStatelessSessionBean (from spring).
>
> Could be a CL problem... the application is using Spring 1.1.4, which
> is included in the EAR.
>
> In my plan I had to add this to even get the application to init:
>
> <hidden-classes><filter>org.springframework</filter></hidden-classes>
> <hidden-classes><filter>antlr</filter></hidden-classes>
>
> I don't really understand what this does either.
>
> I will try again w/o the spring jars in the ear and see how that
> fairs... though I don't really like to have to be put into this
> situation, where I have to use jars outside of the ear. I personally
> prefer that in theory, but in practice, the more separate jars that I
> have to give to QA/Ops, the more chances of them *ucking it up.
>
> Anyways, I'd imagine there are a many apps out there that will include
> jars in their ear for deployment. G should really do the right thing
> with them... regardless of which is right from a theoretical
> perspective or not.
>
> --jason
>
>
> On 2/13/06, Dain Sundstrom <da...@iq80.com> wrote:
> > On Feb 13, 2006, at 4:43 AM, Aaron Mulder wrote:
> >
> > > On 2/13/06, Jason Dillon <ja...@planet57.com> wrote:
> > >> I will look at it more... I'm not familiar with the proxy gen in G
> > >> yet... but a race condition sounds likely since this problem only
> > >> shows up in multithreaded concurrency test.
> > >
> > > I'm not convinced it's a proxy error. I mean, clearly *something*
> > > happened while calling the remove method, but the message is pretty
> > > vague -- could be a classloader problem, could be something wrong with
> > > the session bean lifecycle, could be something wrong with the test...
> > > I'm hoping that if we look for where that message is generated it'll
> > > suggest what might be going wrong.
> >
> > This is not a proxy error at all. This is caused when calling
> > FastClass.invoke which is a faster version of reflection. IIRC this
> > error normally means that the calling code does not have access to
> > the target method. FWIU, regardless of using reflection or generated
> > byte code, the VM will prevent a caller from accessing a method it
> > would not normally have access to via normal Java code. If the
> > method is private and you attempt to use reflection to invoke it, the
> > VM will throw an IllegalAccessError. This enforcement code gets
> > weird when you attempt to call across class loaders.
> >
> > Anyway, lets start with the basics. Can you post the
> > com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewServi
> > ceBean.ejbRemove () code?
> >
> > BTW, I rewrote this code in OpenEJB head to use plain old reflection
> > (long story), so it shouldn't appear there. I am curious if you can
> > reproduce the problem using reflection. Regardless, this is a
> > problem we need to fix, since we use AbstractMethodOperation all over.
> >
> > -dain
> >
>
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Jason Dillon <ja...@planet57.com>.
MerchantViewServiceBean does not have its own ejbRemote(), it picks it
up from AbstractStatelessSessionBean (from app), which picks it up
from AbstractStatelessSessionBean (from spring).
Could be a CL problem... the application is using Spring 1.1.4, which
is included in the EAR.
In my plan I had to add this to even get the application to init:
<hidden-classes><filter>org.springframework</filter></hidden-classes>
<hidden-classes><filter>antlr</filter></hidden-classes>
I don't really understand what this does either.
I will try again w/o the spring jars in the ear and see how that
fairs... though I don't really like to have to be put into this
situation, where I have to use jars outside of the ear. I personally
prefer that in theory, but in practice, the more separate jars that I
have to give to QA/Ops, the more chances of them *ucking it up.
Anyways, I'd imagine there are a many apps out there that will include
jars in their ear for deployment. G should really do the right thing
with them... regardless of which is right from a theoretical
perspective or not.
--jason
On 2/13/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Feb 13, 2006, at 4:43 AM, Aaron Mulder wrote:
>
> > On 2/13/06, Jason Dillon <ja...@planet57.com> wrote:
> >> I will look at it more... I'm not familiar with the proxy gen in G
> >> yet... but a race condition sounds likely since this problem only
> >> shows up in multithreaded concurrency test.
> >
> > I'm not convinced it's a proxy error. I mean, clearly *something*
> > happened while calling the remove method, but the message is pretty
> > vague -- could be a classloader problem, could be something wrong with
> > the session bean lifecycle, could be something wrong with the test...
> > I'm hoping that if we look for where that message is generated it'll
> > suggest what might be going wrong.
>
> This is not a proxy error at all. This is caused when calling
> FastClass.invoke which is a faster version of reflection. IIRC this
> error normally means that the calling code does not have access to
> the target method. FWIU, regardless of using reflection or generated
> byte code, the VM will prevent a caller from accessing a method it
> would not normally have access to via normal Java code. If the
> method is private and you attempt to use reflection to invoke it, the
> VM will throw an IllegalAccessError. This enforcement code gets
> weird when you attempt to call across class loaders.
>
> Anyway, lets start with the basics. Can you post the
> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewServi
> ceBean.ejbRemove () code?
>
> BTW, I rewrote this code in OpenEJB head to use plain old reflection
> (long story), so it shouldn't appear there. I am curious if you can
> reproduce the problem using reflection. Regardless, this is a
> problem we need to fix, since we use AbstractMethodOperation all over.
>
> -dain
>
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 13, 2006, at 4:43 AM, Aaron Mulder wrote:
> On 2/13/06, Jason Dillon <ja...@planet57.com> wrote:
>> I will look at it more... I'm not familiar with the proxy gen in G
>> yet... but a race condition sounds likely since this problem only
>> shows up in multithreaded concurrency test.
>
> I'm not convinced it's a proxy error. I mean, clearly *something*
> happened while calling the remove method, but the message is pretty
> vague -- could be a classloader problem, could be something wrong with
> the session bean lifecycle, could be something wrong with the test...
> I'm hoping that if we look for where that message is generated it'll
> suggest what might be going wrong.
This is not a proxy error at all. This is caused when calling
FastClass.invoke which is a faster version of reflection. IIRC this
error normally means that the calling code does not have access to
the target method. FWIU, regardless of using reflection or generated
byte code, the VM will prevent a caller from accessing a method it
would not normally have access to via normal Java code. If the
method is private and you attempt to use reflection to invoke it, the
VM will throw an IllegalAccessError. This enforcement code gets
weird when you attempt to call across class loaders.
Anyway, lets start with the basics. Can you post the
com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewServi
ceBean.ejbRemove () code?
BTW, I rewrote this code in OpenEJB head to use plain old reflection
(long story), so it shouldn't appear there. I am curious if you can
reproduce the problem using reflection. Regardless, this is a
problem we need to fix, since we use AbstractMethodOperation all over.
-dain
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 2/13/06, Jason Dillon <ja...@planet57.com> wrote:
> I will look at it more... I'm not familiar with the proxy gen in G
> yet... but a race condition sounds likely since this problem only
> shows up in multithreaded concurrency test.
I'm not convinced it's a proxy error. I mean, clearly *something*
happened while calling the remove method, but the message is pretty
vague -- could be a classloader problem, could be something wrong with
the session bean lifecycle, could be something wrong with the test...
I'm hoping that if we look for where that message is generated it'll
suggest what might be going wrong.
> Is there an existing test for G somewhere? I can commit my work on
> JMeter components if that would be helpful.
I don't think we have Maven launching load tests right now, but I'd
say check the stuff into the sandbox and then at least it'll be there
and we can figure out the best way to integrate it into the main build
or itests or whatever.
Thanks,
Aaron
> On Feb 12, 2006, at 8:39 PM, Aaron Mulder wrote:
>
> > I don't, but have you looked up what it is in StatelessInstanceFactory
> > that generates that message? Perhaps we have a race condition?
> >
> > Aaron
> >
> > On 2/12/06, Jason Dillon <ja...@planet57.com> wrote:
> >> Anyone have any idea why this happens?
> >>
> >> --jason
> >>
> >>
> >> On Feb 10, 2006, at 5:03 PM, Jason Dillon wrote:
> >>
> >>> Anyone have a clue why this would be happening?
> >>>
> >>> I see these exceptions when running concurrency tests; and once this
> >>> occurs the application is blown and I have to restart G to recover.
> >>>
> >>> <snip>
> >>> 17:00:16,689 WARN [StatelessInstanceFactory] Unexpected error
> >>> removing Stateless instance
> >>> java.lang.IllegalAccessError: tried to access class
> >>> org.springframework.ejb.support.AbstractEnterpriseBean from class
> >>> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewS
> >>> er
> >>> viceBean$$FastClassByCGLIB$$e322b03a
> >>> at
> >>> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewS
> >>> er
> >>> viceBean$$FastClassByCGLIB$$e322b03a.invoke(<generated>)
> >>> at org.openejb.dispatch.AbstractMethodOperation.invoke
> >>> (AbstractMethodOperation.java:90)
> >>> at org.openejb.slsb.RemoveMethod.execute
> >>> (RemoveMethod.java:69)
> >>> at org.openejb.dispatch.DispatchInterceptor.invoke
> >>> (DispatchInterceptor.java:72)
> >>> at
> >>> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
> >>> (ComponentContextInterceptor.java:56)
> >>> at org.openejb.ConnectionTrackingInterceptor.invoke
> >>> (ConnectionTrackingInterceptor.java:81)
> >>> at org.openejb.slsb.StatelessInstanceContext.ejbRemove
> >>> (StatelessInstanceContext.java:176)
> >>> at org.openejb.slsb.StatelessInstanceFactory.destroyInstance
> >>> (StatelessInstanceFactory.java:90)
> >>> at org.openejb.util.SoftLimitedInstancePool.release
> >>> (SoftLimitedInstancePool.java:95)
> >>> at org.openejb.slsb.StatelessInstanceContext.exit
> >>> (StatelessInstanceContext.java:116)
> >>> at
> >>> org.apache.geronimo.transaction.context.AbstractTransactionContext.e
> >>> nd
> >>> Invocation(AbstractTransactionContext.java:95)
> >>> at org.openejb.slsb.StatelessInstanceInterceptor.invoke
> >>> (StatelessInstanceInterceptor.java:105)
> >>> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> >>> (ContainerPolicy.java:119)
> >>> at
> >>> org.openejb.transaction.TransactionContextInterceptor.invoke
> >>> (TransactionContextInterceptor.java:80)
> >>> at org.openejb.SystemExceptionInterceptor.invoke
> >>> (SystemExceptionInterceptor.java:82)
> >>> at org.openejb.GenericEJBContainer.invoke
> >>> (GenericEJBContainer.java:238)
> >>> at org.openejb.proxy.EJBMethodInterceptor.intercept
> >>> (EJBMethodInterceptor.java:129)
> >>> at org.openejb.proxy.SessionEJBLocalObject$$EnhancerByCGLIB$
> >>> $774ce77e.getActiveMerchantACH(<generated>)
> >>> at
> >>> com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean.aut
> >>> ho
> >>> rize(POSCheckServiceBean.java:219)
> >>> at
> >>> com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean$
> >>> $FastClassByCGLIB$$ac29a8c5.invoke(<generated>)
> >>> at org.openejb.dispatch.AbstractMethodOperation.invoke
> >>> (AbstractMethodOperation.java:90)
> >>> at org.openejb.slsb.BusinessMethod.execute
> >>> (BusinessMethod.java:67)
> >>> at org.openejb.dispatch.DispatchInterceptor.invoke
> >>> (DispatchInterceptor.java:72)
> >>> at
> >>> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
> >>> (ComponentContextInterceptor.java:56)
> >>> at org.openejb.ConnectionTrackingInterceptor.invoke
> >>> (ConnectionTrackingInterceptor.java:81)
> >>> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> >>> (ContainerPolicy.java:119)
> >>> at
> >>> org.openejb.transaction.TransactionContextInterceptor.invoke
> >>> (TransactionContextInterceptor.java:80)
> >>> at org.openejb.slsb.StatelessInstanceInterceptor.invoke
> >>> (StatelessInstanceInterceptor.java:98)
> >>> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> >>> (ContainerPolicy.java:140)
> >>> at
> >>> org.openejb.transaction.TransactionContextInterceptor.invoke
> >>> (TransactionContextInterceptor.java:80)
> >>> at org.openejb.SystemExceptionInterceptor.invoke
> >>> (SystemExceptionInterceptor.java:82)
> >>> at org.openejb.GenericEJBContainer.invoke
> >>> (GenericEJBContainer.java:238)
> >>> at org.openejb.server.ejbd.EjbRequestHandler.invoke
> >>> (EjbRequestHandler.java:297)
> >>> at
> >>> org.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHO
> >>> D(
> >>> EjbRequestHandler.java:325)
> >>> at org.openejb.server.ejbd.EjbRequestHandler.processRequest
> >>> (EjbRequestHandler.java:196)
> >>> at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:
> >>> 150)
> >>> at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:
> >>> 87)
> >>> at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$
> >>> $d379d2ff.invoke(<generated>)
> >>> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:
> >>> 53)
> >>> at
> >>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> >>> (FastMethodInvoker.java:38)
> >>> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> >>> (GBeanOperation.java:118)
> >>> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> >>> (GBeanInstance.java:800)
> >>> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> >>> (RawInvoker.java:57)
> >>> at
> >>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> >>> (RawOperationInvoker.java:36)
> >>> at
> >>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> >>> (ProxyMethodInterceptor.java:96)
> >>> at org.activeio.xnet.ServerService$$EnhancerByCGLIB$
> >>> $944b9c52.service(<generated>)
> >>> at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67)
> >>> at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90)
> >>> at org.apache.geronimo.pool.ThreadPool
> >>> $ContextClassLoaderRunnable.run(ThreadPool.java:138)
> >>> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor
> >>> $Worker.run(Unknown
> >>> Source)
> >>> at java.lang.Thread.run(Thread.java:552)
> >>> </snip>
> >>>
> >>> --jason
> >>
> >>
>
>
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Jason Dillon <ja...@planet57.com>.
I will look at it more... I'm not familiar with the proxy gen in G
yet... but a race condition sounds likely since this problem only
shows up in multithreaded concurrency test.
Is there an existing test for G somewhere? I can commit my work on
JMeter components if that would be helpful.
--jason
On Feb 12, 2006, at 8:39 PM, Aaron Mulder wrote:
> I don't, but have you looked up what it is in StatelessInstanceFactory
> that generates that message? Perhaps we have a race condition?
>
> Aaron
>
> On 2/12/06, Jason Dillon <ja...@planet57.com> wrote:
>> Anyone have any idea why this happens?
>>
>> --jason
>>
>>
>> On Feb 10, 2006, at 5:03 PM, Jason Dillon wrote:
>>
>>> Anyone have a clue why this would be happening?
>>>
>>> I see these exceptions when running concurrency tests; and once this
>>> occurs the application is blown and I have to restart G to recover.
>>>
>>> <snip>
>>> 17:00:16,689 WARN [StatelessInstanceFactory] Unexpected error
>>> removing Stateless instance
>>> java.lang.IllegalAccessError: tried to access class
>>> org.springframework.ejb.support.AbstractEnterpriseBean from class
>>> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewS
>>> er
>>> viceBean$$FastClassByCGLIB$$e322b03a
>>> at
>>> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewS
>>> er
>>> viceBean$$FastClassByCGLIB$$e322b03a.invoke(<generated>)
>>> at org.openejb.dispatch.AbstractMethodOperation.invoke
>>> (AbstractMethodOperation.java:90)
>>> at org.openejb.slsb.RemoveMethod.execute
>>> (RemoveMethod.java:69)
>>> at org.openejb.dispatch.DispatchInterceptor.invoke
>>> (DispatchInterceptor.java:72)
>>> at
>>> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
>>> (ComponentContextInterceptor.java:56)
>>> at org.openejb.ConnectionTrackingInterceptor.invoke
>>> (ConnectionTrackingInterceptor.java:81)
>>> at org.openejb.slsb.StatelessInstanceContext.ejbRemove
>>> (StatelessInstanceContext.java:176)
>>> at org.openejb.slsb.StatelessInstanceFactory.destroyInstance
>>> (StatelessInstanceFactory.java:90)
>>> at org.openejb.util.SoftLimitedInstancePool.release
>>> (SoftLimitedInstancePool.java:95)
>>> at org.openejb.slsb.StatelessInstanceContext.exit
>>> (StatelessInstanceContext.java:116)
>>> at
>>> org.apache.geronimo.transaction.context.AbstractTransactionContext.e
>>> nd
>>> Invocation(AbstractTransactionContext.java:95)
>>> at org.openejb.slsb.StatelessInstanceInterceptor.invoke
>>> (StatelessInstanceInterceptor.java:105)
>>> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
>>> (ContainerPolicy.java:119)
>>> at
>>> org.openejb.transaction.TransactionContextInterceptor.invoke
>>> (TransactionContextInterceptor.java:80)
>>> at org.openejb.SystemExceptionInterceptor.invoke
>>> (SystemExceptionInterceptor.java:82)
>>> at org.openejb.GenericEJBContainer.invoke
>>> (GenericEJBContainer.java:238)
>>> at org.openejb.proxy.EJBMethodInterceptor.intercept
>>> (EJBMethodInterceptor.java:129)
>>> at org.openejb.proxy.SessionEJBLocalObject$$EnhancerByCGLIB$
>>> $774ce77e.getActiveMerchantACH(<generated>)
>>> at
>>> com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean.aut
>>> ho
>>> rize(POSCheckServiceBean.java:219)
>>> at
>>> com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean$
>>> $FastClassByCGLIB$$ac29a8c5.invoke(<generated>)
>>> at org.openejb.dispatch.AbstractMethodOperation.invoke
>>> (AbstractMethodOperation.java:90)
>>> at org.openejb.slsb.BusinessMethod.execute
>>> (BusinessMethod.java:67)
>>> at org.openejb.dispatch.DispatchInterceptor.invoke
>>> (DispatchInterceptor.java:72)
>>> at
>>> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
>>> (ComponentContextInterceptor.java:56)
>>> at org.openejb.ConnectionTrackingInterceptor.invoke
>>> (ConnectionTrackingInterceptor.java:81)
>>> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
>>> (ContainerPolicy.java:119)
>>> at
>>> org.openejb.transaction.TransactionContextInterceptor.invoke
>>> (TransactionContextInterceptor.java:80)
>>> at org.openejb.slsb.StatelessInstanceInterceptor.invoke
>>> (StatelessInstanceInterceptor.java:98)
>>> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
>>> (ContainerPolicy.java:140)
>>> at
>>> org.openejb.transaction.TransactionContextInterceptor.invoke
>>> (TransactionContextInterceptor.java:80)
>>> at org.openejb.SystemExceptionInterceptor.invoke
>>> (SystemExceptionInterceptor.java:82)
>>> at org.openejb.GenericEJBContainer.invoke
>>> (GenericEJBContainer.java:238)
>>> at org.openejb.server.ejbd.EjbRequestHandler.invoke
>>> (EjbRequestHandler.java:297)
>>> at
>>> org.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHO
>>> D(
>>> EjbRequestHandler.java:325)
>>> at org.openejb.server.ejbd.EjbRequestHandler.processRequest
>>> (EjbRequestHandler.java:196)
>>> at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:
>>> 150)
>>> at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:
>>> 87)
>>> at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$
>>> $d379d2ff.invoke(<generated>)
>>> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:
>>> 53)
>>> at
>>> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
>>> (FastMethodInvoker.java:38)
>>> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
>>> (GBeanOperation.java:118)
>>> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
>>> (GBeanInstance.java:800)
>>> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
>>> (RawInvoker.java:57)
>>> at
>>> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
>>> (RawOperationInvoker.java:36)
>>> at
>>> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
>>> (ProxyMethodInterceptor.java:96)
>>> at org.activeio.xnet.ServerService$$EnhancerByCGLIB$
>>> $944b9c52.service(<generated>)
>>> at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67)
>>> at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90)
>>> at org.apache.geronimo.pool.ThreadPool
>>> $ContextClassLoaderRunnable.run(ThreadPool.java:138)
>>> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor
>>> $Worker.run(Unknown
>>> Source)
>>> at java.lang.Thread.run(Thread.java:552)
>>> </snip>
>>>
>>> --jason
>>
>>
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I don't, but have you looked up what it is in StatelessInstanceFactory
that generates that message? Perhaps we have a race condition?
Aaron
On 2/12/06, Jason Dillon <ja...@planet57.com> wrote:
> Anyone have any idea why this happens?
>
> --jason
>
>
> On Feb 10, 2006, at 5:03 PM, Jason Dillon wrote:
>
> > Anyone have a clue why this would be happening?
> >
> > I see these exceptions when running concurrency tests; and once this
> > occurs the application is blown and I have to restart G to recover.
> >
> > <snip>
> > 17:00:16,689 WARN [StatelessInstanceFactory] Unexpected error
> > removing Stateless instance
> > java.lang.IllegalAccessError: tried to access class
> > org.springframework.ejb.support.AbstractEnterpriseBean from class
> > com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewSer
> > viceBean$$FastClassByCGLIB$$e322b03a
> > at
> > com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewSer
> > viceBean$$FastClassByCGLIB$$e322b03a.invoke(<generated>)
> > at org.openejb.dispatch.AbstractMethodOperation.invoke
> > (AbstractMethodOperation.java:90)
> > at org.openejb.slsb.RemoveMethod.execute(RemoveMethod.java:69)
> > at org.openejb.dispatch.DispatchInterceptor.invoke
> > (DispatchInterceptor.java:72)
> > at
> > org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
> > (ComponentContextInterceptor.java:56)
> > at org.openejb.ConnectionTrackingInterceptor.invoke
> > (ConnectionTrackingInterceptor.java:81)
> > at org.openejb.slsb.StatelessInstanceContext.ejbRemove
> > (StatelessInstanceContext.java:176)
> > at org.openejb.slsb.StatelessInstanceFactory.destroyInstance
> > (StatelessInstanceFactory.java:90)
> > at org.openejb.util.SoftLimitedInstancePool.release
> > (SoftLimitedInstancePool.java:95)
> > at org.openejb.slsb.StatelessInstanceContext.exit
> > (StatelessInstanceContext.java:116)
> > at
> > org.apache.geronimo.transaction.context.AbstractTransactionContext.end
> > Invocation(AbstractTransactionContext.java:95)
> > at org.openejb.slsb.StatelessInstanceInterceptor.invoke
> > (StatelessInstanceInterceptor.java:105)
> > at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> > (ContainerPolicy.java:119)
> > at
> > org.openejb.transaction.TransactionContextInterceptor.invoke
> > (TransactionContextInterceptor.java:80)
> > at org.openejb.SystemExceptionInterceptor.invoke
> > (SystemExceptionInterceptor.java:82)
> > at org.openejb.GenericEJBContainer.invoke
> > (GenericEJBContainer.java:238)
> > at org.openejb.proxy.EJBMethodInterceptor.intercept
> > (EJBMethodInterceptor.java:129)
> > at org.openejb.proxy.SessionEJBLocalObject$$EnhancerByCGLIB$
> > $774ce77e.getActiveMerchantACH(<generated>)
> > at
> > com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean.autho
> > rize(POSCheckServiceBean.java:219)
> > at
> > com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean$
> > $FastClassByCGLIB$$ac29a8c5.invoke(<generated>)
> > at org.openejb.dispatch.AbstractMethodOperation.invoke
> > (AbstractMethodOperation.java:90)
> > at org.openejb.slsb.BusinessMethod.execute
> > (BusinessMethod.java:67)
> > at org.openejb.dispatch.DispatchInterceptor.invoke
> > (DispatchInterceptor.java:72)
> > at
> > org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
> > (ComponentContextInterceptor.java:56)
> > at org.openejb.ConnectionTrackingInterceptor.invoke
> > (ConnectionTrackingInterceptor.java:81)
> > at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> > (ContainerPolicy.java:119)
> > at
> > org.openejb.transaction.TransactionContextInterceptor.invoke
> > (TransactionContextInterceptor.java:80)
> > at org.openejb.slsb.StatelessInstanceInterceptor.invoke
> > (StatelessInstanceInterceptor.java:98)
> > at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> > (ContainerPolicy.java:140)
> > at
> > org.openejb.transaction.TransactionContextInterceptor.invoke
> > (TransactionContextInterceptor.java:80)
> > at org.openejb.SystemExceptionInterceptor.invoke
> > (SystemExceptionInterceptor.java:82)
> > at org.openejb.GenericEJBContainer.invoke
> > (GenericEJBContainer.java:238)
> > at org.openejb.server.ejbd.EjbRequestHandler.invoke
> > (EjbRequestHandler.java:297)
> > at
> > org.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(
> > EjbRequestHandler.java:325)
> > at org.openejb.server.ejbd.EjbRequestHandler.processRequest
> > (EjbRequestHandler.java:196)
> > at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:
> > 150)
> > at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:
> > 87)
> > at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$
> > $d379d2ff.invoke(<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> > at
> > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> > (FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> > (GBeanOperation.java:118)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> > (GBeanInstance.java:800)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> > (RawInvoker.java:57)
> > at
> > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> > (RawOperationInvoker.java:36)
> > at
> > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> > (ProxyMethodInterceptor.java:96)
> > at org.activeio.xnet.ServerService$$EnhancerByCGLIB$
> > $944b9c52.service(<generated>)
> > at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67)
> > at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90)
> > at org.apache.geronimo.pool.ThreadPool
> > $ContextClassLoaderRunnable.run(ThreadPool.java:138)
> > at EDU.oswego.cs.dl.util.concurrent.PooledExecutor
> > $Worker.run(Unknown
> > Source)
> > at java.lang.Thread.run(Thread.java:552)
> > </snip>
> >
> > --jason
>
>
Re: Strange IllegalAccessError w/FastClassByCGLIB class
Posted by Jason Dillon <ja...@planet57.com>.
Anyone have any idea why this happens?
--jason
On Feb 10, 2006, at 5:03 PM, Jason Dillon wrote:
> Anyone have a clue why this would be happening?
>
> I see these exceptions when running concurrency tests; and once this
> occurs the application is blown and I have to restart G to recover.
>
> <snip>
> 17:00:16,689 WARN [StatelessInstanceFactory] Unexpected error
> removing Stateless instance
> java.lang.IllegalAccessError: tried to access class
> org.springframework.ejb.support.AbstractEnterpriseBean from class
> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewSer
> viceBean$$FastClassByCGLIB$$e322b03a
> at
> com.solidusnetworks.paycore.ach.model.merchant.service.MerchantViewSer
> viceBean$$FastClassByCGLIB$$e322b03a.invoke(<generated>)
> at org.openejb.dispatch.AbstractMethodOperation.invoke
> (AbstractMethodOperation.java:90)
> at org.openejb.slsb.RemoveMethod.execute(RemoveMethod.java:69)
> at org.openejb.dispatch.DispatchInterceptor.invoke
> (DispatchInterceptor.java:72)
> at
> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
> (ComponentContextInterceptor.java:56)
> at org.openejb.ConnectionTrackingInterceptor.invoke
> (ConnectionTrackingInterceptor.java:81)
> at org.openejb.slsb.StatelessInstanceContext.ejbRemove
> (StatelessInstanceContext.java:176)
> at org.openejb.slsb.StatelessInstanceFactory.destroyInstance
> (StatelessInstanceFactory.java:90)
> at org.openejb.util.SoftLimitedInstancePool.release
> (SoftLimitedInstancePool.java:95)
> at org.openejb.slsb.StatelessInstanceContext.exit
> (StatelessInstanceContext.java:116)
> at
> org.apache.geronimo.transaction.context.AbstractTransactionContext.end
> Invocation(AbstractTransactionContext.java:95)
> at org.openejb.slsb.StatelessInstanceInterceptor.invoke
> (StatelessInstanceInterceptor.java:105)
> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> (ContainerPolicy.java:119)
> at
> org.openejb.transaction.TransactionContextInterceptor.invoke
> (TransactionContextInterceptor.java:80)
> at org.openejb.SystemExceptionInterceptor.invoke
> (SystemExceptionInterceptor.java:82)
> at org.openejb.GenericEJBContainer.invoke
> (GenericEJBContainer.java:238)
> at org.openejb.proxy.EJBMethodInterceptor.intercept
> (EJBMethodInterceptor.java:129)
> at org.openejb.proxy.SessionEJBLocalObject$$EnhancerByCGLIB$
> $774ce77e.getActiveMerchantACH(<generated>)
> at
> com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean.autho
> rize(POSCheckServiceBean.java:219)
> at
> com.solidusnetworks.paycore.ach.business.pos.POSCheckServiceBean$
> $FastClassByCGLIB$$ac29a8c5.invoke(<generated>)
> at org.openejb.dispatch.AbstractMethodOperation.invoke
> (AbstractMethodOperation.java:90)
> at org.openejb.slsb.BusinessMethod.execute
> (BusinessMethod.java:67)
> at org.openejb.dispatch.DispatchInterceptor.invoke
> (DispatchInterceptor.java:72)
> at
> org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke
> (ComponentContextInterceptor.java:56)
> at org.openejb.ConnectionTrackingInterceptor.invoke
> (ConnectionTrackingInterceptor.java:81)
> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> (ContainerPolicy.java:119)
> at
> org.openejb.transaction.TransactionContextInterceptor.invoke
> (TransactionContextInterceptor.java:80)
> at org.openejb.slsb.StatelessInstanceInterceptor.invoke
> (StatelessInstanceInterceptor.java:98)
> at org.openejb.transaction.ContainerPolicy$TxRequired.invoke
> (ContainerPolicy.java:140)
> at
> org.openejb.transaction.TransactionContextInterceptor.invoke
> (TransactionContextInterceptor.java:80)
> at org.openejb.SystemExceptionInterceptor.invoke
> (SystemExceptionInterceptor.java:82)
> at org.openejb.GenericEJBContainer.invoke
> (GenericEJBContainer.java:238)
> at org.openejb.server.ejbd.EjbRequestHandler.invoke
> (EjbRequestHandler.java:297)
> at
> org.openejb.server.ejbd.EjbRequestHandler.doEjbObject_BUSINESS_METHOD(
> EjbRequestHandler.java:325)
> at org.openejb.server.ejbd.EjbRequestHandler.processRequest
> (EjbRequestHandler.java:196)
> at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:
> 150)
> at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:
> 87)
> at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$
> $d379d2ff.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:118)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:800)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:36)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.activeio.xnet.ServerService$$EnhancerByCGLIB$
> $944b9c52.service(<generated>)
> at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67)
> at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90)
> at org.apache.geronimo.pool.ThreadPool
> $ContextClassLoaderRunnable.run(ThreadPool.java:138)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor
> $Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:552)
> </snip>
>
> --jason