[
https://issues.apache.org/jira/browse/FELIX-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113010#comment-16113010
]
Karl Pauls commented on FELIX-5665:
-----------------------------------
[~aattuluri], I'm a little pressed for time atm - however, I think I know what
is going on namely,
jog4j is walking the stack and tries to load the classes it finds itself. It
apparently does so in hopes to get more information as it otherwise would get.
This is causing the problem since only the classloader of the class reflected
upon knows about the generated access class - hence, when log4j is trying to
load it using its classloader, it can't find the class because all we can do is
to bootdelegate but we can't find the right classloader of the defining class.
In other words, I don't think that this is a bug in felix. Arguably, we could
try to make this an improvement where we try to either detect the situation
early so that you at least don't suffer from the performance impacts
(basically, we would terminate the search for sun.reflect.Generated* at the
same point where we terminate java.* searches) or we try to somehow find the
correct classload by magic.
Right now, I'm thinking that the former would be the best solution. Maybe with
a property to disable it. WDYT?
> 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
> Fix For: framework-5.6.8
>
> 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)
