Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache result of AopUtils.canApply [SPR-7328] #11987

Closed
spring-projects-issues opened this issue Jun 27, 2010 · 10 comments
Closed

Cache result of AopUtils.canApply [SPR-7328] #11987

spring-projects-issues opened this issue Jun 27, 2010 · 10 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 27, 2010

Leigh Anderson opened SPR-7328 and commented

Profiling of our struts2/Spring 2.5.6 App in Tomcat showed AopUtils.canApply as being a hotspot in terms of CPU usage -- we make extensive use of AOP with annotations. The attached patch helps ameliorate this.

Patch is against SVN trunk as of 28/06/10.


Affects: 2.5.6

Attachments:

Issue Links:

2 votes, 6 watchers

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

I suppose that you're using a lot of non-singleton beans with aspects applied against them... since that's the only scenario where canApply is being invoked repeatedly, for every new bean instance. Is that assumption correct?

In any case, optimizing this in a general manner is non-trivial, so I'm scheduling this for the Spring 3.1 generation.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Leigh Anderson commented

That's correct. We are using Spring with the Struts2 -> Spring bridge. Each web request requires the instantiation of the Struts action, which is a Spring-managed bean.

@spring-projects-issues
Copy link
Collaborator Author

Leigh Anderson commented

Has any further consideration has been given to this? I've just hit a similar issue in a different context with Spring 3.0.5. Use case is basically the same: a lot of request- or prototype- scoped beans with annotations.

@spring-projects-issues
Copy link
Collaborator Author

Fernando Kasten Peinado commented

We had the same problem, lots of prototype e request scoped beans. We patched our 3.0.6 spring and got a great improvement in performance measures (2.2s to 350 ms) in one of our cases.

There is any chance that this patch be applied in the versions 3.0.X and 3.1.X? Or at least on the new ones?

Kasten

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

OK, I'm putting this onto the 3.2 schedule, for consideration in RC1. There is a chance for this to be backported to 3.1.3 as well.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

We've addressed this in all BeanPostProcessors that call into AopUtils.canApply now. In general, we intend to do any further such caching in canApply's clients as well, not in the canApply implementation itself.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Testo Nakano commented

How was it fixed? I still don't see any changes in AnnotationAwareAspectJAutoProxyCreator/AspectJAwareAdvisorAutoProxyCreator/AbstractAdvisorAutoProxyCreator?

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Well, all classes derived from AbstractAutoProxyCreator have been caching advised beans and related metadata for a long time anyway. This issue was rather about some special BeanPostProcessors implementations not doing it: This is what we addressed for 3.2, performing such caching in all affected places other than AutoProxyCreators as well.

Let me know if we've been missing something. As far as we understand, such caching should be consistently applied across our AOP infrastructure options now.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

For concrete insight into how this post-processor issue was resolved, have a look at the newly introduced org.springframework.aop.framework.AbstractAdvisingBeanPostProcessor base class.

@spring-projects-issues
Copy link
Collaborator Author

Testo Nakano commented

Ah, I just realized that the code has been changed significantly after Spring 3.0. Let me try it out.

AopUtils.canApply(Pointcut, Class<?>, boolean) line: 200
AopUtils.canApply(Advisor, Class<?>, boolean) line: 254
AopUtils.findAdvisorsThatCanApply(List<Advisor>, Class<?>) line: 286
AnnotationAwareAspectJAutoProxyCreator(AbstractAdvisorAutoProxyCreator).findAdvisorsThatCanApply(List<Advisor>, Class, String) line: 117
AnnotationAwareAspectJAutoProxyCreator(AbstractAdvisorAutoProxyCreator).findEligibleAdvisors(Class, String) line: 87
AnnotationAwareAspectJAutoProxyCreator(AbstractAdvisorAutoProxyCreator).getAdvicesAndAdvisorsForBean(Class, String, TargetSource) line: 68
AnnotationAwareAspectJAutoProxyCreator(AbstractAutoProxyCreator).wrapIfNecessary(Object, String, Object) line: 359
AnnotationAwareAspectJAutoProxyCreator(AbstractAutoProxyCreator).postProcessAfterInitialization(Object, String) line: 322
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).applyBeanPostProcessorsAfterInitialization(Object, String) line: 407
DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).postProcessObjectFromFactoryBean(Object, String) line: 1561
DefaultListableBeanFactory(FactoryBeanRegistrySupport).doGetObjectFromFactoryBean(FactoryBean, String, boolean) line: 162
DefaultListableBeanFactory(FactoryBeanRegistrySupport).getObjectFromFactoryBean(FactoryBean, String, boolean) line: 102
DefaultListableBeanFactory(AbstractBeanFactory).getObjectForBeanInstance(Object, String, String, RootBeanDefinition) line: 1440
DefaultListableBeanFactory(AbstractBeanFactory).doGetBean(String, Class<T>, Object[], boolean) line: 247
DefaultListableBeanFactory(AbstractBeanFactory).getBean(String, Class<T>) line: 196
DefaultListableBeanFactory(AbstractBeanFactory).doGetBean(String, Class<T>, Object[], boolean) line: 268
DefaultListableBeanFactory(AbstractBeanFactory).getBean(String) line: 192

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants