[
https://issues.apache.org/jira/browse/FELIX-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101973#comment-16101973
]
AnilKumar Attuluri edited comment on FELIX-5665 at 7/26/17 5:44 PM:
--------------------------------------------------------------------
[~karlpauls]
I have created a gradle project here:
https://github.com/anilutcs/osgi-reflection-test
It has the instructions to build, run (on karaf) and test.
Here are the findings that might be helpful:
Its the apache log4j library that tries to load the class
*_sun.reflect.GeneratedMethodAccessor<number>_* which ends up in the method
*BundleWiringImpl.findClassOrResourceByDelegation* which in turn ends up
looking up for that class everywhere (boot delegation, current class loader,
search imports and including the dynamic imports) and then throws a
*ClassNotFoundException*.
So obviously its CPU expensive since this happens several times for every app
call. Let me know if there is a hack to delegate this to some other class
loader without impacting the current class loading. Apparently boot delegation
didn't work.
Here is the stacktrace from the project I created showing
GeneratedMethodAccessors when its run (you should see that under
*/var/log/reflection-test.log* - You can change this in
reflection/src/main/resources/log4j2.xml):
{code:java}
at com.intuit.osgi.reflection.StageTwo.applyMethod(StageTwo.java:42)
~[reflection-latest.jar:?]
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) ~[?:?]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_91]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_91]
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
~[reflection-latest.jar:?]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
~[reflection-latest.jar:?]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
~[reflection-latest.jar:?]
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:85)
~[reflection-latest.jar:?]
at
com.intuit.osgi.reflection.StageAspect.profileSync(StageAspect.java:37)
~[reflection-latest.jar:?]
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source) ~[?:?]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_91]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_91]
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
~[reflection-latest.jar:?]
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
~[reflection-latest.jar:?]
at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:68)
~[reflection-latest.jar:?]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
~[reflection-latest.jar:?]
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
~[reflection-latest.jar:?]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
~[reflection-latest.jar:?]
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
~[reflection-latest.jar:?]
at com.sun.proxy.$Proxy48.applyMethod(Unknown Source) ~[?:?]
at
com.intuit.osgi.reflection.RequestHandler.handle(RequestHandler.java:55)
[reflection-latest.jar:?]
{code}
was (Author: aattuluri):
[~karlpauls]
I have created a gradle project here:
https://github.com/anilutcs/osgi-reflection-test
It has the instructions to build, run (on karaf) and test.
Here are the findings that might be helpful:
Its the apache log4j library that tries to load the class
*_sun.reflect.GeneratedMethodAccessor<number>_* which ends up in the method
*BundleWiringImpl.findClassOrResourceByDelegation* which in turn ends up
looking up for that class everywhere (boot delegation, current class loader,
search imports and including the dynamic imports) and then throws a
*ClassNotFoundException*.
So obviously its CPU expensive since this happens several times for every app
call. Let me know if there is a hack to delegate this to some other class
loader without impacting the current class loading. Apparently boot delegation
didn't work.
> High CPU usage on
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation
> ---------------------------------------------------------------------------------------------
>
> Key: FELIX-5665
> URL: https://issues.apache.org/jira/browse/FELIX-5665
> Project: Felix
> Issue Type: Bug
> Affects Versions: framework-5.6.4
> Reporter: AnilKumar Attuluri
> Attachments: IMG_1.jpg, IMG_2.jpg
>
>
> We have been running some performance tests to prepare our OSGi bundle
> (*running in Apache Karaf*) for production.
> Just to give some background about our OSGi bundle, we converted an existing
> Spring application into an OSGi bundle with all the current dependencies
> packaged into the bundle as an uber artifact.
> When we run >= 500 TPS (each of these calls results in a http call made via a
> library) we run into this high CPU usage spikes reaching up to 100% CPU.
> Please see the image attached, the spikes in the image are 100% CPU usage
> while the average is about 40%. Also see the CPU sampler image which points
> to
> *org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation*
> Is there an existing bug/documentation that already captures this?
> We don't see this behavior when we run the same app in standalone JVM.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
