No, there's no rush here. We're able to hack around the problem effectively in our own code. Thanks for your response!
leo igor.vaynberg wrote: > > as far as i can see the problem is "on the other side of the fence". > applicationcontext has much better metadata about its beans then we do > so it should be cached there as it can be done so properly. > > if this is urgent we can build a temporary cache into > springbeanlocator, but its not the proper thing to do imho. if we > follow this logic then we can actually start caching bean references > as well and essentially build our own applicationcontext.... > > > -igor > > On Thu, Dec 11, 2008 at 1:33 PM, leok <[email protected]> wrote: >> >> Hello, >> >> Our Wicket app makes use of the @SpringBean annotation thorughout our >> code, >> which is a pretty cool feature. While checking some thread stack traces >> during load testing, we found lots of threads bottlenecking in the >> SpringBeanLocator class: >> >> Object blocked: 145.133 ms, Object wait: 0 ms, CPU wait: 2.118 ms, I/O >> wait: >> 9.017 ms, CPU: 73.847 ms >> >> * >> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton >> (DefaultSingletonBeanRegistry.java:180, bci=22, server compiler) >> o blocked on java.util.concurrent.ConcurrentHashMap >> (0x000000cd67f9d170) >> * >> org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch >> (AbstractBeanFactory.java:415, bci=41, server compiler) >> * >> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType >> (DefaultListableBeanFactory.java:223, bci=142, server compiler) >> * >> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType >> (DefaultListableBeanFactory.java:202, bci=4, server compiler) >> * >> org.springframework.context.support.AbstractApplicationContext.getBeanNamesForType >> (AbstractApplicationContext.java:933, bci=5, server compiler) >> * >> org.springframework.beans.factory.BeanFactoryUtils.beanNamesForTypeIncludingAncestors >> (BeanFactoryUtils.java:143, bci=8, server compiler) >> * org.apache.wicket.spring.SpringBeanLocator.getBeanNameOfClass >> (SpringBeanLocator.java:104, bci=2, server compiler) >> * org.apache.wicket.spring.SpringBeanLocator.getBeanName >> (SpringBeanLocator.java:192, bci=29, server compiler) >> * org.apache.wicket.spring.SpringBeanLocator.isSingletonBean >> (SpringBeanLocator.java:133, bci=13, server compiler) >> * >> org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue >> (AnnotProxyFieldValueFactory.java:90, bci=46, server compiler) >> * org.apache.wicket.injection.Injector.inject (Injector.java:108, >> bci=87, server compiler) >> * org.apache.wicket.injection.ConfigurableInjector.inject >> (ConfigurableInjector.java:39, bci=6, server compiler) >> * org.apache.wicket.injection.ComponentInjector.onInstantiation >> (ComponentInjector.java:52, bci=5, server compiler) >> * org.apache.wicket.Application.notifyComponentInstantiationListeners >> (Application.java:974, bci=20, server compiler) >> * org.apache.wicket.Component.<init> (Component.java:873, bci=35, >> server >> compiler) >> * org.apache.wicket.MarkupContainer.<init> (MarkupContainer.java:105, >> bci=2, server compiler) >> * org.apache.wicket.markup.html.WebMarkupContainer.<init> >> (WebMarkupContainer.java:39, bci=2, server compiler) >> * >> org.apache.wicket.markup.html.WebMarkupContainerWithAssociatedMarkup.<init> >> (WebMarkupContainerWithAssociatedMarkup.java:42, bci=2, server compiler) >> * org.apache.wicket.markup.html.panel.Panel.<init> (Panel.java:76, >> bci=2, server compiler) >> [...snip...] >> >> I found that if we specified a name in @SpringBean (e.g. @SpringBean(name >> = >> "foo")), then we would avoid this bottlenecking and our requests per >> second >> improved 50-75%. It appears that the SpringBeanLocator.isSingletonBean() >> call will do an expensive lookup of the bean name against >> BeanFactoryUtils.beanNamesForTypeIncludingAncestors() if the name isn't >> specified, even if the bean is already cached. By specifying the >> @SpringBean >> name parameter, you avoid the lookup. >> >> This feels like a bug, though I don't know who to should address it, >> Wicket >> or Spring. Specifying a name in @SpringBean is optional, and the >> performance >> gain of a cache lookup of already-injected beans is consequently defeated >> by >> the isSingletonBean() call, which is called every single time a >> SpringBean >> is injected. This implies Wicket should be addressing it. OTOH, Spring >> BeanFactoryUtils.beanNamesForTypeIncludingAncestors() is clearly a >> bottleneck if called too frequently, though when I've found performance >> issues in Spring code (e.g. >> http://jira.springframework.org/browse/SPR-4505) >> they've implied that Wicket should have better bean caching (though >> they've >> fixed them anyway). >> >> So.. how would one go about addressing this problem? It's a big >> performance >> issue for those deploying a Wicket app using @SpringBean on multi-core >> systems. I'm able to hack around it in our app, but not knowing much >> about >> how Spring and Wicket should be interacting I'm not sure I can give an >> educated guess. >> >> Thanks, >> leo >> -- >> View this message in context: >> http://www.nabble.com/SpringBeanLocator-and-%40SpringBean-performance-issue-tp20964687p20964687.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- View this message in context: http://www.nabble.com/SpringBeanLocator-and-%40SpringBean-performance-issue-tp20964687p20979661.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
