You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2010/10/23 01:25:46 UTC
Re: NoClassDefFoundError after 15 method calls
Resurrecting an old thread from users@felix...
Stuart, I'm trying to create a test case to create this scenario, but am
having no luck. All I did was create a proxy and then try to call its
method a lot of times. I never see a class load request to the module
class loader for sun.reflect even though the proxy class was defined
using it. Is there something I'm missing?
I'm trying to rewrite/simplify our rules for implicit boot delegation
and we have some code in the current version to try to handle Proxy when
it is on the call stack, however, I don't see why we have it or how it
helps.
Clement, was this issue actually just a bug in iPOJO
(https://issues.apache.org/jira/browse/FELIX-2416) and had nothing to do
with the framework?
-> richard
On 6/17/10 1:29, Stuart McCulloch wrote:
> 2010/6/17 Issac Noé García<is...@torito.org>
>
>> Hi, this is my first post here,
>> I have a bug I can solve :(
>> The context:
>> The platform: I'm using iPOJO 1.6.2, Felix 2.0.5, Jetty 1.0.1, XMLRPC or
>> JsonRPC
>> The application :
>> I have two iPOJO components (service-exporter and real-service)
>> service-exporter requires the real-service and expose it as a Json RPC
>> service.
>>
>> Its a simple application the real-service is like a "hello world"example.
>> And I use a frontend using jscript to call the json service, and everything
>> is OK, but only 15 calls!! I need to update the bundle to have it running
>> again (another 15 calls)
>> Later, I changed the JSON RPC exporter for an XMLRPC exporter to see if it
>> was an Jabsorb problem. but it throws the exception after 15 services calls
>> too.
>>
>> Someone has an idea about what its happening here?
>>
> it's a proxy classloader issue, we encountered the same thing with Guice a
> while ago:
>
> http://code.google.com/p/google-guice/issues/detail?id=417
>
> basically the issue is that after ~15 method calls the Sun JDK proxy code
> switches
> from using native reflection to a generated class (the class is better for
> JIT compiling
> but it takes longer to create than a few native reflection calls, hence the
> threshold)
>
> to make this switch the proxy instance needs access to the "sun.reflect"
> classes,
> which are usually available from the boot classloader via parent delegation
> - but if
> the proxy instance was created by an OSGi bundle then it could end up using
> the
> bundle's classloader (depending on the type being proxied)
>
> this is where it gets problematic - if the proxy is using a bundle
> classloader and
> that bundle doesn't import "sun.reflect" then it won't be able to see this
> package
> and you get that exception... and the bundle typically won't import
> "sun.reflect"
> as it's a hidden JVM implementation issue
>
> so what to do? for Guice we already use a custom (bridge) classloader for
> bundle
> created proxies, so we simple added a shortcut to load any "sun.reflect"
> classes
> via the system classloader - maybe iPOJO could so something similar?
>
> otherwise there is a simple workaround, which is to set this framework
> property:
>
> org.osgi.framework.bootdelegation=sun.reflect
>
> in the Felix configuration file - then all bundles will be able to see the
> "sun.reflect"
> package without having to import it (some use a wider pattern of
> "sun.*,com.sun.*")
>
> HTH
>
> the trace exception is here:
>> java.lang.NoClassDefFoundError: sun/reflect/MethodAccessorImpl
>> at sun.misc.Unsafe.defineClass(Native Method)
>> at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
>> at
>> sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at
>>
>> sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
>> at
>>
>> sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:59)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:28)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>>
>> org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.invoke(ReflectiveXmlRpcHandler.java:115)
>> at
>>
>> org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:106)
>> at
>>
>> org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:46)
>> at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:86)
>> at
>>
>> org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:200)
>> at
>>
>> org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:112)
>> at org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:196)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
>> at
>>
>> org.mortbay.jetty.servlet.OsgiServletHolder.handle(OsgiServletHolder.java:101)
>> at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363)
>> at
>>
>> org.mortbay.jetty.servlet.OsgiServletHandler.handle(OsgiServletHandler.java:117)
>> at
>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>> at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>> at org.mortbay.jetty.Server.handle(Server.java:324)
>> at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
>> at
>>
>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:741)
>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:213)
>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
>> at
>>
>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
>> at
>>
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
>> Caused by: java.lang.ClassNotFoundException: sun.reflect.MethodAccessorImpl
>> at
>>
>> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:814)
>> at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61)
>> at
>>
>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>> at
>>
>> org.apache.felix.ipojo.handlers.dependency.Dependency$SmartProxyFactory.loadClass(Dependency.java:900)
>> ... 33 more
>>
>> --
>> Issac Noé García Garza
>>
Re: NoClassDefFoundError after 15 method calls
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/23/10 0:51, Clement Escoffier wrote:
> Hi,
>
> On 23.10.2010, at 01:25, Richard S. Hall wrote:
>
>> Resurrecting an old thread from users@felix...
>>
>> Stuart, I'm trying to create a test case to create this scenario, but am having no luck. All I did was create a proxy and then try to call its method a lot of times. I never see a class load request to the module class loader for sun.reflect even though the proxy class was defined using it. Is there something I'm missing?
>>
>> I'm trying to rewrite/simplify our rules for implicit boot delegation and we have some code in the current version to try to handle Proxy when it is on the call stack, however, I don't see why we have it or how it helps.
>>
>> Clement, was this issue actually just a bug in iPOJO (https://issues.apache.org/jira/browse/FELIX-2416) and had nothing to do with the framework?
> It was a bug in the framework. I did nothing in this area. Issac reported that it was working with the framework 3.1.0-SNAPSHOT.
Any ideas on recreating it?
-> richard
>
> Regards,
>
> Clement
>
>> -> richard
>>
>> On 6/17/10 1:29, Stuart McCulloch wrote:
>>> 2010/6/17 Issac Noé García<is...@torito.org>
>>>
>>>> Hi, this is my first post here,
>>>> I have a bug I can solve :(
>>>> The context:
>>>> The platform: I'm using iPOJO 1.6.2, Felix 2.0.5, Jetty 1.0.1, XMLRPC or
>>>> JsonRPC
>>>> The application :
>>>> I have two iPOJO components (service-exporter and real-service)
>>>> service-exporter requires the real-service and expose it as a Json RPC
>>>> service.
>>>>
>>>> Its a simple application the real-service is like a "hello world"example.
>>>> And I use a frontend using jscript to call the json service, and everything
>>>> is OK, but only 15 calls!! I need to update the bundle to have it running
>>>> again (another 15 calls)
>>>> Later, I changed the JSON RPC exporter for an XMLRPC exporter to see if it
>>>> was an Jabsorb problem. but it throws the exception after 15 services calls
>>>> too.
>>>>
>>>> Someone has an idea about what its happening here?
>>>>
>>> it's a proxy classloader issue, we encountered the same thing with Guice a
>>> while ago:
>>>
>>> http://code.google.com/p/google-guice/issues/detail?id=417
>>>
>>> basically the issue is that after ~15 method calls the Sun JDK proxy code
>>> switches
>>> from using native reflection to a generated class (the class is better for
>>> JIT compiling
>>> but it takes longer to create than a few native reflection calls, hence the
>>> threshold)
>>>
>>> to make this switch the proxy instance needs access to the "sun.reflect"
>>> classes,
>>> which are usually available from the boot classloader via parent delegation
>>> - but if
>>> the proxy instance was created by an OSGi bundle then it could end up using
>>> the
>>> bundle's classloader (depending on the type being proxied)
>>>
>>> this is where it gets problematic - if the proxy is using a bundle
>>> classloader and
>>> that bundle doesn't import "sun.reflect" then it won't be able to see this
>>> package
>>> and you get that exception... and the bundle typically won't import
>>> "sun.reflect"
>>> as it's a hidden JVM implementation issue
>>>
>>> so what to do? for Guice we already use a custom (bridge) classloader for
>>> bundle
>>> created proxies, so we simple added a shortcut to load any "sun.reflect"
>>> classes
>>> via the system classloader - maybe iPOJO could so something similar?
>>>
>>> otherwise there is a simple workaround, which is to set this framework
>>> property:
>>>
>>> org.osgi.framework.bootdelegation=sun.reflect
>>>
>>> in the Felix configuration file - then all bundles will be able to see the
>>> "sun.reflect"
>>> package without having to import it (some use a wider pattern of
>>> "sun.*,com.sun.*")
>>>
>>> HTH
>>>
>>> the trace exception is here:
>>>> java.lang.NoClassDefFoundError: sun/reflect/MethodAccessorImpl
>>>> at sun.misc.Unsafe.defineClass(Native Method)
>>>> at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
>>>> at
>>>> sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>> at
>>>>
>>>> sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
>>>> at
>>>>
>>>> sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:59)
>>>> at
>>>>
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:28)
>>>> at
>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at
>>>>
>>>> org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.invoke(ReflectiveXmlRpcHandler.java:115)
>>>> at
>>>>
>>>> org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:106)
>>>> at
>>>>
>>>> org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:46)
>>>> at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:86)
>>>> at
>>>>
>>>> org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:200)
>>>> at
>>>>
>>>> org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:112)
>>>> at org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:196)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>>> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
>>>> at
>>>>
>>>> org.mortbay.jetty.servlet.OsgiServletHolder.handle(OsgiServletHolder.java:101)
>>>> at
>>>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363)
>>>> at
>>>>
>>>> org.mortbay.jetty.servlet.OsgiServletHandler.handle(OsgiServletHandler.java:117)
>>>> at
>>>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>>>> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>>>> at
>>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>>> at org.mortbay.jetty.Server.handle(Server.java:324)
>>>> at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
>>>> at
>>>>
>>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
>>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:741)
>>>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:213)
>>>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
>>>> at
>>>>
>>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
>>>> at
>>>>
>>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
>>>> Caused by: java.lang.ClassNotFoundException: sun.reflect.MethodAccessorImpl
>>>> at
>>>>
>>>> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:814)
>>>> at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61)
>>>> at
>>>>
>>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>>>> at
>>>>
>>>> org.apache.felix.ipojo.handlers.dependency.Dependency$SmartProxyFactory.loadClass(Dependency.java:900)
>>>> ... 33 more
>>>>
>>>> --
>>>> Issac Noé García Garza
>>>>
Re: NoClassDefFoundError after 15 method calls
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 23.10.2010, at 01:25, Richard S. Hall wrote:
> Resurrecting an old thread from users@felix...
>
> Stuart, I'm trying to create a test case to create this scenario, but am having no luck. All I did was create a proxy and then try to call its method a lot of times. I never see a class load request to the module class loader for sun.reflect even though the proxy class was defined using it. Is there something I'm missing?
>
> I'm trying to rewrite/simplify our rules for implicit boot delegation and we have some code in the current version to try to handle Proxy when it is on the call stack, however, I don't see why we have it or how it helps.
>
> Clement, was this issue actually just a bug in iPOJO (https://issues.apache.org/jira/browse/FELIX-2416) and had nothing to do with the framework?
It was a bug in the framework. I did nothing in this area. Issac reported that it was working with the framework 3.1.0-SNAPSHOT.
Regards,
Clement
>
> -> richard
>
> On 6/17/10 1:29, Stuart McCulloch wrote:
>> 2010/6/17 Issac Noé García<is...@torito.org>
>>
>>> Hi, this is my first post here,
>>> I have a bug I can solve :(
>>> The context:
>>> The platform: I'm using iPOJO 1.6.2, Felix 2.0.5, Jetty 1.0.1, XMLRPC or
>>> JsonRPC
>>> The application :
>>> I have two iPOJO components (service-exporter and real-service)
>>> service-exporter requires the real-service and expose it as a Json RPC
>>> service.
>>>
>>> Its a simple application the real-service is like a "hello world"example.
>>> And I use a frontend using jscript to call the json service, and everything
>>> is OK, but only 15 calls!! I need to update the bundle to have it running
>>> again (another 15 calls)
>>> Later, I changed the JSON RPC exporter for an XMLRPC exporter to see if it
>>> was an Jabsorb problem. but it throws the exception after 15 services calls
>>> too.
>>>
>>> Someone has an idea about what its happening here?
>>>
>> it's a proxy classloader issue, we encountered the same thing with Guice a
>> while ago:
>>
>> http://code.google.com/p/google-guice/issues/detail?id=417
>>
>> basically the issue is that after ~15 method calls the Sun JDK proxy code
>> switches
>> from using native reflection to a generated class (the class is better for
>> JIT compiling
>> but it takes longer to create than a few native reflection calls, hence the
>> threshold)
>>
>> to make this switch the proxy instance needs access to the "sun.reflect"
>> classes,
>> which are usually available from the boot classloader via parent delegation
>> - but if
>> the proxy instance was created by an OSGi bundle then it could end up using
>> the
>> bundle's classloader (depending on the type being proxied)
>>
>> this is where it gets problematic - if the proxy is using a bundle
>> classloader and
>> that bundle doesn't import "sun.reflect" then it won't be able to see this
>> package
>> and you get that exception... and the bundle typically won't import
>> "sun.reflect"
>> as it's a hidden JVM implementation issue
>>
>> so what to do? for Guice we already use a custom (bridge) classloader for
>> bundle
>> created proxies, so we simple added a shortcut to load any "sun.reflect"
>> classes
>> via the system classloader - maybe iPOJO could so something similar?
>>
>> otherwise there is a simple workaround, which is to set this framework
>> property:
>>
>> org.osgi.framework.bootdelegation=sun.reflect
>>
>> in the Felix configuration file - then all bundles will be able to see the
>> "sun.reflect"
>> package without having to import it (some use a wider pattern of
>> "sun.*,com.sun.*")
>>
>> HTH
>>
>> the trace exception is here:
>>> java.lang.NoClassDefFoundError: sun/reflect/MethodAccessorImpl
>>> at sun.misc.Unsafe.defineClass(Native Method)
>>> at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
>>> at
>>> sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at
>>>
>>> sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
>>> at
>>>
>>> sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:59)
>>> at
>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:28)
>>> at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>> at
>>>
>>> org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.invoke(ReflectiveXmlRpcHandler.java:115)
>>> at
>>>
>>> org.apache.xmlrpc.server.ReflectiveXmlRpcHandler.execute(ReflectiveXmlRpcHandler.java:106)
>>> at
>>>
>>> org.apache.xmlrpc.server.XmlRpcServerWorker.execute(XmlRpcServerWorker.java:46)
>>> at org.apache.xmlrpc.server.XmlRpcServer.execute(XmlRpcServer.java:86)
>>> at
>>>
>>> org.apache.xmlrpc.server.XmlRpcStreamServer.execute(XmlRpcStreamServer.java:200)
>>> at
>>>
>>> org.apache.xmlrpc.webserver.XmlRpcServletServer.execute(XmlRpcServletServer.java:112)
>>> at org.apache.xmlrpc.webserver.XmlRpcServlet.doPost(XmlRpcServlet.java:196)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
>>> at
>>>
>>> org.mortbay.jetty.servlet.OsgiServletHolder.handle(OsgiServletHolder.java:101)
>>> at
>>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363)
>>> at
>>>
>>> org.mortbay.jetty.servlet.OsgiServletHandler.handle(OsgiServletHandler.java:117)
>>> at
>>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>>> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>>> at
>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>> at org.mortbay.jetty.Server.handle(Server.java:324)
>>> at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
>>> at
>>>
>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879)
>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:741)
>>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:213)
>>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
>>> at
>>>
>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
>>> at
>>>
>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
>>> Caused by: java.lang.ClassNotFoundException: sun.reflect.MethodAccessorImpl
>>> at
>>>
>>> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:814)
>>> at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61)
>>> at
>>>
>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1733)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>>> at
>>>
>>> org.apache.felix.ipojo.handlers.dependency.Dependency$SmartProxyFactory.loadClass(Dependency.java:900)
>>> ... 33 more
>>>
>>> --
>>> Issac Noé García Garza
>>>