Details

Description

It appears that Spring prototype (non-singleton) bean factory creations cause synchronization contention issues under load.
The NavigationalState and PortalURL beans are created several times per request.
Under load with JMeter tests, the synchronization of Java Bean support code (in the JDK), called by Spring's bean factory, was causing severe performance degradation.
Removing this bottleneck improved performance by 5X.
I've attached the Java source from the package java.beans. I believe its these synchronized methods of the java.beans.PropertyEditorManager class that are causing the contention:

David Sean Taylor
added a comment - 27/Apr/07 17:40 Also see:
http://opensource.atlassian.com/projects/spring/browse/SPR-3426
As an immediate patch, we are looking into creating a custom Spring bean factory to handle creation of the Portal URL and NavigationalState prototypes (non-singletons)

for this particular case you probably don't need to create custom bean factory to handle the creation of Portal URL instances. You could just configure Spring to use a factory method defined someplace (instead of using constructor). This factory method could contain the actual code:

Dmitry Bisikalo
added a comment - 27/Apr/07 20:07 David,
for this particular case you probably don't need to create custom bean factory to handle the creation of Portal URL instances. You could just configure Spring to use a factory method defined someplace (instead of using constructor). This factory method could contain the actual code:
public PortalURL createPortalURL()
{
NavigationalStateCodec codec = (NavigationalStateCodec)beanFactory.getBean("NavigationalStateCodec");
JetspeedCache cache = (JetspeedCache)beanFactory.getBean("portletContentCache");
NavigationalState navState = new SessionFullNavigationalState( codec, cache);
PortalContext context = (PortalContext)beanFactory.getBean("PortalContext");
PortalURL url = new PathInfoEncodingPortalURL(navState, context);
}
This factory method code would encapsulate the optimized logic (i.e. would call "new" directly, as defined above), but from the calling code perspective it would still look like this:
PortalURL url = (PortalURL) beanFactory.getBean(urlBeanName);
Having this code encapsulated in the factory method would allow you externalize the logic, but would save you the trouble of creating specialized bean factory.

We have four different Portal URL implementations that can easily be configured with the Spring configuration files.
If we take this approach above, we would have to require a recompile for everytime someone wanted to switch Portal URL implementations

David Sean Taylor
added a comment - 27/Apr/07 20:58 We have four different Portal URL implementations that can easily be configured with the Spring configuration files.
If we take this approach above, we would have to require a recompile for everytime someone wanted to switch Portal URL implementations