Joerg Hoh created OAK-11894:
-------------------------------
Summary: DocViewImport: Resolve the IdentifierManager lazily
Key: OAK-11894
URL: https://issues.apache.org/jira/browse/OAK-11894
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Affects Versions: 1.84.0
Reporter: Joerg Hoh
The ImporterImpl class always initializes the ImporterImpl.IdResolver, which
can block in import situations like this:
{noformat}
at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
- parking to wait for <0x00000007c6ce7000> (a
java.util.concurrent.Semaphore$FairSync)
at
java.util.concurrent.locks.LockSupport.parkNanos([email protected]/LockSupport.java:269)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire([email protected]/AbstractQueuedSynchronizer.java:756)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos([email protected]/AbstractQueuedSynchronizer.java:1126)
at
java.util.concurrent.Semaphore.tryAcquire([email protected]/Semaphore.java:415)
at
org.apache.jackrabbit.oak.segment.scheduler.LockBasedScheduler.getHeadNodeState(LockBasedScheduler.java:219)
at
org.apache.jackrabbit.oak.segment.SegmentNodeStore.getRoot(SegmentNodeStore.java:199)
at
org.apache.jackrabbit.oak.core.MutableRoot.<init>(MutableRoot.java:174)
at
org.apache.jackrabbit.oak.core.ContentSessionImpl.getLatestRoot(ContentSessionImpl.java:109)
at
org.apache.jackrabbit.oak.jcr.xml.ImporterImpl$IdResolver.<init>(ImporterImpl.java:593)
at
org.apache.jackrabbit.oak.jcr.xml.ImporterImpl.<init>(ImporterImpl.java:159)
at
org.apache.jackrabbit.oak.jcr.xml.ImportHandler.<init>(ImportHandler.java:77)
at
org.apache.jackrabbit.oak.jcr.session.SessionImpl.getImportContentHandler(SessionImpl.java:528)
at
org.apache.jackrabbit.vault.fs.impl.io.DocViewImporter.createNewNode(DocViewImporter.java:1117)
{noformat}
As the IdentifierManager (for which construction the
{{ContentSessionImpl.getLastestRoot()}} is resolved) is not required all the
time (actually it's only required if conflicting UUID is detected), we can save
time and compute this only when required.
I benchmarked on an otherwise idle system a small improvement in the range of
2-3%, but I suspect a major improvement in case there are concurrent write
operations during the package installation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
