[
https://issues.apache.org/jira/browse/OAK-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18008086#comment-18008086
]
Joerg Hoh commented on OAK-11782:
---------------------------------
In OAK-11810 a fix is provided, which reduces the need to access the Whiteboard
to retrieve that service, which improves the performance in many situations
when content is imported.
Nevertheless we should try to implement an approach to avoid hitting the
registry over and over.
> UserImporter: use a global tracker for the UserMonitor.class
> ------------------------------------------------------------
>
> Key: OAK-11782
> URL: https://issues.apache.org/jira/browse/OAK-11782
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
> Affects Versions: 1.78.0
> Reporter: Joerg Hoh
> Priority: Major
>
> In AEM we often import large content packges via filevault. Tracking the
> process I frequently see this stacktrace:
> {noformat}
> at java.util.HashMap.putMapEntries(java.base@11.0.24/HashMap.java:508)
> at java.util.HashMap.<init>(java.base@11.0.24/HashMap.java:486)
> at
> org.apache.felix.framework.EventDispatcher.addListenerInfo(EventDispatcher.java:1028)
> at
> org.apache.felix.framework.EventDispatcher.addListener(EventDispatcher.java:243)
> - locked <0x000000058fdc1120> (a
> org.apache.felix.framework.EventDispatcher)
> at org.apache.felix.framework.Felix.addServiceListener(Felix.java:3642)
> at
> org.apache.felix.framework.BundleContextImpl.addServiceListener(BundleContextImpl.java:259)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:298)
> - locked <0x00000007859b2bc0> (a
> org.osgi.util.tracker.ServiceTracker$Tracked)
> - locked <0x00000007859b29b0> (a org.osgi.util.tracker.ServiceTracker)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:265)
> at
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.track(OsgiWhiteboard.java:161)
> at
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.track(OsgiWhiteboard.java:113)
> at
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.track(OsgiWhiteboard.java:108)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.getService(WhiteboardUtils.java:186)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.getService(WhiteboardUtils.java:145)
> at
> org.apache.jackrabbit.oak.security.user.UserImporter.init(UserImporter.java:215)
> at
> org.apache.jackrabbit.oak.jcr.xml.ImporterImpl.<init>(ImporterImpl.java:169)
> at
> org.apache.jackrabbit.oak.jcr.xml.ImportHandler.<init>(ImportHandler.java:76)
> at
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.getImportContentHandler(SessionImpl.java:527)
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.createNewNode(DocViewImporter.java:1110)
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.addNode(DocViewImporter.java:928)
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.startDocViewNode(DocViewImporter.java:407)
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXHandler.startElement(DocViewSAXHandler.java:348)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(java.xml@11.0.24/AbstractSAXParser.java:510)
> {noformat}
> In this area the JCR XML ImportHandler tries to get retrieven the UserMonitor
> service from the OSGI service registry. This is not per se a problem, but
> when installing packages of 10k+ nodes this overhead can take a significant
> amount of time (5-8% of the total duration); and according to my dumps the
> problem is not the actual retrieval of the service, but rather the creation
> of the Service Tracker.
> To reduce this I suggest that we should make the Tracker a global object (a
> static member of the UserImporter class, being populated on first access),
> which will eliminate these frequent accesses to the OSGI Service Registry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
