-
Notifications
You must be signed in to change notification settings - Fork 38k
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
Comments
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 |
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. |
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. |
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 |
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 |
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 |
Testo Nakano commented How was it fixed? I still don't see any changes in AnnotationAwareAspectJAutoProxyCreator/AspectJAwareAdvisorAutoProxyCreator/AbstractAdvisorAutoProxyCreator? |
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 |
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. |
Testo Nakano commented Ah, I just realized that the code has been changed significantly after Spring 3.0. Let me try it out.
|
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
The text was updated successfully, but these errors were encountered: