You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Willem Jiang (JIRA)" <ji...@apache.org> on 2011/04/08 10:15:06 UTC
[jira] [Created] (SMX4-803) OsgiLocator causes huge performance
bottlenecks
OsgiLocator causes huge performance bottlenecks
-----------------------------------------------
Key: SMX4-803
URL: https://issues.apache.org/jira/browse/SMX4-803
Project: ServiceMix 4
Issue Type: Improvement
Components: Bundles
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: specs-1.8.0
org.apache.servicemix.specs.locator.OsgiLocator is inlined into many SMX specs bundles. If someone uese any of these APIs heavily, OsgiLocator causes serious performance degradation. In most cases this happens if somebody uses the given API incorrectly and does not reuse objects (factories). In our case it is CXF's SAAJ IN interceptor that most probably incorrectly uses SAAJ API (MessageFactory).
Anyway, the problem is that:
1) OsgiLocator's methods are all static synchronized. If many threads try to get a SAAJ factory, they start jamming in locate(String factoryId) as it is synchronized. For example this CXF stuff might cause it:
{code}
at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:86)
at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:85)
at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.getFactory(SAAJInInterceptor.java:88)
- locked [0x00002aac03ea1628] (a org.apache.cxf.binding.soap.saaj.SAAJInInterceptor)
at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:100)
at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:71)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
- locked [0x00002aac07fb9908] (a org.apache.cxf.phase.PhaseInterceptorChain)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)
at com.sabre.cxf.extensions.transport.http.JettyContentExchange.doTaskCompleted(JettyContentExchange.java:244)
at com.sabre.cxf.extensions.transport.http.JettyContentExchange.onResponseComplete(JettyContentExchange.java:107)
at org.mortbay.jetty.client.HttpExchange$Listener.onResponseComplete(HttpExchange.java:730)
at org.mortbay.jetty.client.HttpExchange.setStatus(HttpExchange.java:194)
at org.mortbay.jetty.client.HttpConnection$Handler.messageComplete(HttpConnection.java:517)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:761)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:245)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{code}
In order to get rid of this issue OSGiLocator should start using a ReentrantReadWriteLock instead of the synchronized keyword. Attached is a modified version OSGi locator that uses ReentrantReadWriteLock . However, a problem is still observed ...See #2.
2) After OSGiLocator was hacked, a bottleneck was identified deeper - in the bundle classloader:
{code}
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:293)
- waiting to lock [0x00002aabf6230d80] (a sun.misc.Launcher$AppClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:438)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:338)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:232)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1197)
at org.apache.servicemix.specs.locator.Activator$BundleFactoryLoader.call(Activator.java:149)
at org.apache.servicemix.specs.locator.Activator$BundleFactoryLoader.call(Activator.java:131)
at org.apache.servicemix.specs.locator.OsgiLocator.locate(OsgiLocator.java:75)
at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:86)
at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:85)
at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.getFactory(SAAJInInterceptor.java:88)
- locked [0x00002aac03ea1628] (a org.apache.cxf.binding.soap.saaj.SAAJInInterceptor)
at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:100)
at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:71)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
- locked [0x00002aac07fb9908] (a org.apache.cxf.phase.PhaseInterceptorChain)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)
at com.sabre.cxf.extensions.transport.http.JettyContentExchange.doTaskCompleted(JettyContentExchange.java:244)
at com.sabre.cxf.extensions.transport.http.JettyContentExchange.onResponseComplete(JettyContentExchange.java:107)
at org.mortbay.jetty.client.HttpExchange$Listener.onResponseComplete(HttpExchange.java:730)
at org.mortbay.jetty.client.HttpExchange.setStatus(HttpExchange.java:194)
at org.mortbay.jetty.client.HttpConnection$Handler.messageComplete(HttpConnection.java:517)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:761)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:245)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{code}
It might be reasonable to change Activator.BundleFactoryLoader to cache the implementation class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SMX4-803) OsgiLocator causes huge performance
bottlenecks
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SMX4-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Willem Jiang resolved SMX4-803.
-------------------------------
Resolution: Fixed
Applied patch into specs.
> OsgiLocator causes huge performance bottlenecks
> -----------------------------------------------
>
> Key: SMX4-803
> URL: https://issues.apache.org/jira/browse/SMX4-803
> Project: ServiceMix 4
> Issue Type: Improvement
> Components: Bundles
> Reporter: Willem Jiang
> Assignee: Willem Jiang
> Fix For: specs-1.8.0
>
>
> org.apache.servicemix.specs.locator.OsgiLocator is inlined into many SMX specs bundles. If someone uese any of these APIs heavily, OsgiLocator causes serious performance degradation. In most cases this happens if somebody uses the given API incorrectly and does not reuse objects (factories). In our case it is CXF's SAAJ IN interceptor that most probably incorrectly uses SAAJ API (MessageFactory).
> Anyway, the problem is that:
> 1) OsgiLocator's methods are all static synchronized. If many threads try to get a SAAJ factory, they start jamming in locate(String factoryId) as it is synchronized. For example this CXF stuff might cause it:
> {code}
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:86)
> at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:85)
> at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.getFactory(SAAJInInterceptor.java:88)
> - locked [0x00002aac03ea1628] (a org.apache.cxf.binding.soap.saaj.SAAJInInterceptor)
> at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:100)
> at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:71)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> - locked [0x00002aac07fb9908] (a org.apache.cxf.phase.PhaseInterceptorChain)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)
> at com.sabre.cxf.extensions.transport.http.JettyContentExchange.doTaskCompleted(JettyContentExchange.java:244)
> at com.sabre.cxf.extensions.transport.http.JettyContentExchange.onResponseComplete(JettyContentExchange.java:107)
> at org.mortbay.jetty.client.HttpExchange$Listener.onResponseComplete(HttpExchange.java:730)
> at org.mortbay.jetty.client.HttpExchange.setStatus(HttpExchange.java:194)
> at org.mortbay.jetty.client.HttpConnection$Handler.messageComplete(HttpConnection.java:517)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:761)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
> at org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:245)
> at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
> at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> {code}
> In order to get rid of this issue OSGiLocator should start using a ReentrantReadWriteLock instead of the synchronized keyword. Attached is a modified version OSGi locator that uses ReentrantReadWriteLock . However, a problem is still observed ...See #2.
> 2) After OSGiLocator was hacked, a bottleneck was identified deeper - in the bundle classloader:
> {code}
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:293)
> - waiting to lock [0x00002aabf6230d80] (a sun.misc.Launcher$AppClassLoader)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:438)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
> at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:338)
> at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:232)
> at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1197)
> at org.apache.servicemix.specs.locator.Activator$BundleFactoryLoader.call(Activator.java:149)
> at org.apache.servicemix.specs.locator.Activator$BundleFactoryLoader.call(Activator.java:131)
> at org.apache.servicemix.specs.locator.OsgiLocator.locate(OsgiLocator.java:75)
> at javax.xml.soap.FactoryFinder.find(FactoryFinder.java:86)
> at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:85)
> at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.getFactory(SAAJInInterceptor.java:88)
> - locked [0x00002aac03ea1628] (a org.apache.cxf.binding.soap.saaj.SAAJInInterceptor)
> at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:100)
> at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:71)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> - locked [0x00002aac07fb9908] (a org.apache.cxf.phase.PhaseInterceptorChain)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:737)
> at com.sabre.cxf.extensions.transport.http.JettyContentExchange.doTaskCompleted(JettyContentExchange.java:244)
> at com.sabre.cxf.extensions.transport.http.JettyContentExchange.onResponseComplete(JettyContentExchange.java:107)
> at org.mortbay.jetty.client.HttpExchange$Listener.onResponseComplete(HttpExchange.java:730)
> at org.mortbay.jetty.client.HttpExchange.setStatus(HttpExchange.java:194)
> at org.mortbay.jetty.client.HttpConnection$Handler.messageComplete(HttpConnection.java:517)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:761)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
> at org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:245)
> at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
> at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> {code}
> It might be reasonable to change Activator.BundleFactoryLoader to cache the implementation class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira