[
https://issues.apache.org/jira/browse/OAK-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated OAK-11782:
----------------------------
Epic Link: OAK-11821
Description:
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.
was:
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.
> 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)
