Issue 1:
Adam Causey opened SPR-7959 and commented

The class org.springframework.web.servlet.view.document.AbstractPdfView references the iText PDF library using the package com.lowagie.. The most recent version of iText uses the package com.itextpdf. instead of com.lowagie.

The current workaround is to use an older version of iText, but it would be nice to have this updated.

Thanks.

Affects: 3.0.5

Issue Links:

#12083 Update the AbstractPdfView class to point to the renamed itextpdf package names ("is duplicated by")

1 votes, 4 watchers

Issue 2:
Leo Kim opened SPR-5360 and commented

I actually wrote to the Wicket mailing list initially about this:

http://www.nabble.com/SpringBeanLocator-and-%40SpringBean-performance-issue-td20964687.html

and they suggest that this is a deeper Spring issue. Basically, I'm using Wicket's @SpringBean annotation to inject beans throughout our webapp. When we load tested the app, we found threads blocking for extended periods at this particular point:

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...]

We're able to hack around it in our code and avoid this bottleneck, which resulted in us getting 50-75% more requests per second. Looking at some of the Spring 3.0 code, it looks like this class has not changed much so we'll probably run into this problem when we upgrade. Is there a way to make this code path more concurrent? With Spring 3.0 using Java 5, it seems like the use of read/write locks might squeeze more concurrency out of these bean lookups.

Affects: 2.5.6

Attachments:

NonBlockingWebApplicationContext.java (4.05 kB)

Issue Links:

#14452 Non-singleton beans performance issue ("duplicates")

#13410 Parallel bean initialization during startup

10 votes, 14 watchers