[ 
https://issues.apache.org/jira/browse/FELIX-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16123093#comment-16123093
 ] 

Karl Pauls commented on FELIX-5665:
-----------------------------------

[~aattuluri] furthermore, if my patch works for you we might want to look into 
optimising it a little more. I think it should be possible to use the lookup 
map to cache successful lookups as well. I.e., we should keep track of 
revisions we loaded an accessor class from so that we don't have to iterate 
over all revisions again for the same classname. Basically, we would change the 
negative check to be: if the key exists but the value is null we failed to load 
the class before. If the key exists and the value is a revision, load the class 
from that classloader of that revision. Otherwise, we haven't seen this request 
before so try to find it and record the result with a null if we can't and the 
revision if we can. Obviously, we need yet another sentinel value for the 
classpath (i.e., if we managed to load it from the classpath via 
bootdelegation). In that case, maybe we just put the current bundle revision 
and check for that with an == or something.

> 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: FELIX-5665.patch, 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)

Reply via email to