[
https://issues.apache.org/jira/browse/FELIX-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121597#comment-16121597
]
Karl Pauls commented on FELIX-5665:
-----------------------------------
[~aattuluri], I think there are a couple of points I'm not sure about wrt. to
your patch namely,
In the first place, I think if we do this we should either find a general
solution or at a minimum, make it so that we do this for at least all generated
accessor kind of classes (as opposed to only the method accessor kind of
classes). Not sure there are ones for fields but it looks like there is for
sure ones for constructors as well.
In the second place, I think your solution is to broad in the sense that it
will prevent generated accessors to be found for classes on the classpath
(granted, the problem in general is that it would be nice to be able to find
accessor classes for imported classes as well).
Part of me wonders if we shouldn't try to be smarter with the solution to this
problem. What we really would want to do is to keep a negative lookup cache for
the classpath and for all imported revisions and make sure we at least try to
load the classes one time and then remember if it didn't work. However, that
might be a little too much work for now.
Regardless, a release by tomorrow is not going to happen. It will be a couple
of weeks before I get to it.
> High CPU usage on sun.reflect.Generated* class loads by log4j
> --------------------------------------------------------------
>
> Key: FELIX-5665
> URL: https://issues.apache.org/jira/browse/FELIX-5665
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> 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)
