[jira] [Updated] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8023:
Labels: candidate_oak_1_8 (was: candidate_oak_1_10)
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Labels: candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8023-2.patch, OAK-8023-3.patch, OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8068: Fix Version/s: 1.10.1 > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0, 1.10.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774879#comment-16774879
]
Andrei Dulceanu commented on OAK-8071:
--
{quote}Do you remember why this check for the number of available permits was
put in place?
{quote}
AFAICR, this was the only method for determining if a certain commit will be
executed right away or will be queued, because the semaphore was already
acquired.
Regarding your concern about a race condition, I'm not sure how this could
happen. IMO, the worst thing that could happen is that a thread which initially
sees that no permits are available is marked as queued, even though the thread
which acquired the semaphore released it in the mean time (after the if check).
Following this point, only one thread will be able to execute commits (having
already acquired the semaphore).
[~mduerig], WDYT about the reasoning above?
> Logging to detect commits carrying over from previous GC generation can block
> other threads from committing
> ---
>
> Key: OAK-8071
> URL: https://issues.apache.org/jira/browse/OAK-8071
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>
> Add logging / monitoring to detect the situation from OAK-8014.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774027#comment-16774027 ] Julian Reschke edited comment on OAK-8068 at 2/22/19 7:51 AM: -- trunk: [r1854044|http://svn.apache.org/r1854044] 1.10: [r1854116|http://svn.apache.org/r1854116] was (Author: reschke): trunk: [r1854044|http://svn.apache.org/r1854044] > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8068: Labels: candidate_oak_1_8 (was: candidate_oak_1_10) > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8067) Measure fsync (called when closing the NRT index) and try to reduce disk I/O
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774863#comment-16774863
]
Thomas Mueller commented on OAK-8067:
-
http://svn.apache.org/r1854115 (trunk)
FYI [~catholicon]
> Measure fsync (called when closing the NRT index) and try to reduce disk I/O
>
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
>
[jira] [Updated] (OAK-8067) Measure fsync (called when closing the NRT index) and try to reduce disk I/O
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-8067:
Summary: Measure fsync (called when closing the NRT index) and try to
reduce disk I/O (was: Measure fsync (called when closing the NRT index))
> Measure fsync (called when closing the NRT index) and try to reduce disk I/O
>
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
>
[jira] [Commented] (OAK-8067) Measure fsync (called when closing the NRT index)
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774850#comment-16774850
]
Thomas Mueller commented on OAK-8067:
-
As we have "FileUtils.deleteQuietly(indexDir)" right after closing, I think it
should be fine to also call "deleteAll()" before closing. deleteQuietly will
just try to delete, and errors to delete are silently ignored. So possibly it's
not always deleted. So, I'm not sure about concurrent usage of the index, what
happens in case of power failure, or when the index isn't removed.
I will add "deleteAll" by default, but use a different setting that allows to
disable just that.
> Measure fsync (called when closing the NRT index)
> -
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
>
[jira] [Commented] (OAK-8073) Build Jackrabbit Oak #1966 failed
[ https://issues.apache.org/jira/browse/OAK-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774861#comment-16774861 ] Hudson commented on OAK-8073: - Build is still failing. Failed run: [Jackrabbit Oak #1967|https://builds.apache.org/job/Jackrabbit%20Oak/1967/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1967/console] > Build Jackrabbit Oak #1966 failed > - > > Key: OAK-8073 > URL: https://issues.apache.org/jira/browse/OAK-8073 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1966 has failed. > First failed run: [Jackrabbit Oak > #1966|https://builds.apache.org/job/Jackrabbit%20Oak/1966/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1966/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8074) RDB*Store: update mysql-connector-java dependency to 8.0.15
[ https://issues.apache.org/jira/browse/OAK-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8074: Labels: candidate_oak_1_10 (was: ) > RDB*Store: update mysql-connector-java dependency to 8.0.15 > --- > > Key: OAK-8074 > URL: https://issues.apache.org/jira/browse/OAK-8074 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8074) RDB*Store: update mysql-connector-java dependency to 8.0.15
Julian Reschke created OAK-8074: --- Summary: RDB*Store: update mysql-connector-java dependency to 8.0.15 Key: OAK-8074 URL: https://issues.apache.org/jira/browse/OAK-8074 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 1.12 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8074) RDB*Store: update mysql-connector-java dependency to 8.0.15
[ https://issues.apache.org/jira/browse/OAK-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774777#comment-16774777 ] Julian Reschke commented on OAK-8074: - trunk: [r1854113|http://svn.apache.org/r1854113] > RDB*Store: update mysql-connector-java dependency to 8.0.15 > --- > > Key: OAK-8074 > URL: https://issues.apache.org/jira/browse/OAK-8074 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8074) RDB*Store: update mysql-connector-java dependency to 8.0.15
[ https://issues.apache.org/jira/browse/OAK-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-8074. - Resolution: Fixed Fix Version/s: 1.11.0 > RDB*Store: update mysql-connector-java dependency to 8.0.15 > --- > > Key: OAK-8074 > URL: https://issues.apache.org/jira/browse/OAK-8074 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774494#comment-16774494 ] Michael Dürig commented on OAK-8071: At [https://github.com/mduerig/jackrabbit-oak/commit/0dd87632ae6ec2228ac35fcdc8e919982559fb16] I added a timestamp to the monitoring of the queued commits. At the same time I refactored the handling of processing the stack traces a bit deferring their evaluation to the point where they are requested. [~dulceanu], could you have a look? > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773955#comment-16773955
]
Julian Reschke edited comment on OAK-8052 at 2/21/19 5:50 PM:
--
trunk: [r1854034|http://svn.apache.org/r1854034]
1.10: [r1854070|http://svn.apache.org/r1854070]
was (Author: reschke):
trunk: [r1854034|http://svn.apache.org/r1854034]
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8052:
Fix Version/s: 1.10.1
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8052:
Labels: candidate_oak_1_6 candidate_oak_1_8 (was: candidate_oak_1_10
candidate_oak_1_6 candidate_oak_1_8)
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8073) Build Jackrabbit Oak #1966 failed
Hudson created OAK-8073: --- Summary: Build Jackrabbit Oak #1966 failed Key: OAK-8073 URL: https://issues.apache.org/jira/browse/OAK-8073 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #1966 has failed. First failed run: [Jackrabbit Oak #1966|https://builds.apache.org/job/Jackrabbit%20Oak/1966/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1966/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8064) Build Jackrabbit Oak #1960 failed
[ https://issues.apache.org/jira/browse/OAK-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774290#comment-16774290 ] Hudson commented on OAK-8064: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1965|https://builds.apache.org/job/Jackrabbit%20Oak/1965/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1965/console] > Build Jackrabbit Oak #1960 failed > - > > Key: OAK-8064 > URL: https://issues.apache.org/jira/browse/OAK-8064 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1960 has failed. > First failed run: [Jackrabbit Oak > #1960|https://builds.apache.org/job/Jackrabbit%20Oak/1960/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1960/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774229#comment-16774229
]
Michael Dürig commented on OAK-8071:
As prerequisite I propose to remove a potential race condition in the
monitoring of the {{LockBasedScheduler}}: Always handle commits as queued even
when the lock is free to avoid races between checking the number of available
permits and actually acquiring the lock. [~dulceanu], do you remember why this
check for the number of available permits was put in place?
See
[https://github.com/mduerig/jackrabbit-oak/commit/fcc2c85182d16e4838645e3a35c43d358c687421]
> Logging to detect commits carrying over from previous GC generation can block
> other threads from committing
> ---
>
> Key: OAK-8071
> URL: https://issues.apache.org/jira/browse/OAK-8071
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>
> Add logging / monitoring to detect the situation from OAK-8014.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8016) RDBDocumentStore: minor improvements to GZIP compression of BLOB contents
[ https://issues.apache.org/jira/browse/OAK-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757303#comment-16757303 ] Julian Reschke edited comment on OAK-8016 at 2/21/19 3:45 PM: -- trunk: [r1852601|http://svn.apache.org/r1852601] 1.10: [r1854060|http://svn.apache.org/r1854060] was (Author: reschke): trunk: [r1852601|http://svn.apache.org/r1852601] > RDBDocumentStore: minor improvements to GZIP compression of BLOB contents > - > > Key: OAK-8016 > URL: https://issues.apache.org/jira/browse/OAK-8016 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.1 > > > 1. Ensure GZIPOutputStream is closed in the unlikely event of error when > writing to ByteArrayOutputStream > 2. Optionally log sizes and ratios > 3. Slightly improve initial size estimate for ByteArrayOutputStream -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8016) RDBDocumentStore: minor improvements to GZIP compression of BLOB contents
[ https://issues.apache.org/jira/browse/OAK-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8016: Labels: candidate_oak_1_8 (was: candidate_oak_1_10) > RDBDocumentStore: minor improvements to GZIP compression of BLOB contents > - > > Key: OAK-8016 > URL: https://issues.apache.org/jira/browse/OAK-8016 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_8 > Fix For: 1.12, 1.11.0, 1.10.1 > > > 1. Ensure GZIPOutputStream is closed in the unlikely event of error when > writing to ByteArrayOutputStream > 2. Optionally log sizes and ratios > 3. Slightly improve initial size estimate for ByteArrayOutputStream -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8016) RDBDocumentStore: minor improvements to GZIP compression of BLOB contents
[ https://issues.apache.org/jira/browse/OAK-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8016: Fix Version/s: 1.10.1 > RDBDocumentStore: minor improvements to GZIP compression of BLOB contents > - > > Key: OAK-8016 > URL: https://issues.apache.org/jira/browse/OAK-8016 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0, 1.10.1 > > > 1. Ensure GZIPOutputStream is closed in the unlikely event of error when > writing to ByteArrayOutputStream > 2. Optionally log sizes and ratios > 3. Slightly improve initial size estimate for ByteArrayOutputStream -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs
[
https://issues.apache.org/jira/browse/OAK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774188#comment-16774188
]
Julian Reschke edited comment on OAK-8051 at 2/21/19 3:33 PM:
--
bq. I just argue that my patch is slightly better, as it can deal with
interrupt exceptions happening early on. Your patch would fail for this case,
breaking the test case.
The patch broke the test (that's why I @ignored it) because the map wouldn't be
constructed in the first place, not because of the handling of interrupt
exceptions (right?). I still think that would be a clearer contract, but I
accept things are the way they are.
Now the good question is how we can construct a test that replicates the
scenario for which the ticket was opened.
was (Author: reschke):
> I just argue that my patch is slightly better, as it can deal with interrupt
> exceptions happening early on. Your patch would fail for this case, breaking
> the test case.
The patch broke the test (that's why I @ignored it) because the map wouldn't be
constructed in the first place, not because of the handling of interrupt
exceptions (right?). I still think that would be a clearer contract, but I
accept things are the way they are.
Now the good question is how we can construct a test that replicates the
scenario for which the ticket was opened.
> PersistentCache: error during open can lead to incomplete initialization and
> subsequent NPEs
>
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data
> [1.4.193/7]
> at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
> at org.h2.mvstore.FileStore.open(FileStore.java:168)
> at org.h2.mvstore.MVStore.(MVStore.java:348)
> at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the map
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
> at
>
[jira] [Commented] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs
[
https://issues.apache.org/jira/browse/OAK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774188#comment-16774188
]
Julian Reschke commented on OAK-8051:
-
> I just argue that my patch is slightly better, as it can deal with interrupt
> exceptions happening early on. Your patch would fail for this case, breaking
> the test case.
The patch broke the test (that's why I @ignored it) because the map wouldn't be
constructed in the first place, not because of the handling of interrupt
exceptions (right?). I still think that would be a clearer contract, but I
accept things are the way they are.
Now the good question is how we can construct a test that replicates the
scenario for which the ticket was opened.
> PersistentCache: error during open can lead to incomplete initialization and
> subsequent NPEs
>
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data
> [1.4.193/7]
> at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
> at org.h2.mvstore.FileStore.open(FileStore.java:168)
> at org.h2.mvstore.MVStore.(MVStore.java:348)
> at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the map
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.setRDBConnection(DocumentMK.java:757)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStore(DocumentNodeStoreService.java:508)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStoreIfPossible(DocumentNodeStoreService.java:430)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.activate(DocumentNodeStoreService.java:414)
> {noformat}
> and then
> {noformat}
> 22.01.2019 08:45:16.808 *WARN* [http-/0.0.0.0:80-3]
>
[jira] [Updated] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8014:
Fix Version/s: 1.12
> Commits carrying over from previous GC generation can block other threads
> from committing
> -
>
> Key: OAK-8014
> URL: https://issues.apache.org/jira/browse/OAK-8014
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.11
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8014.patch
>
>
> A commit that is based on a previous (full) generation can block other
> commits from progressing for a long time. This happens because such a commit
> will do a deep copy of its state to avoid linking to old segments (see
> OAK-3348). Most of the deep copying is usually avoided by the deduplication
> caches. However, in cases where the cache hit rate is not good enough we have
> seen deep copy operations up to several minutes. Sometimes this deep copy
> operation happens inside the commit lock of
> {{LockBasedScheduler.schedule()}}, which then causes all other commits to
> become blocked.
> cc [~rma61...@adobe.com], [~edivad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8071: Fix Version/s: 1.12 > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8069:
Fix Version/s: 1.12
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: TarMK
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8067) Measure fsync (called when closing the NRT index)
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774143#comment-16774143
]
Thomas Mueller commented on OAK-8067:
-
I removed the "deleteAll" call.
Still, I kept close(false), meaning merge won't be done sometimes. I wonder if
that's a problem or not?
> Measure fsync (called when closing the NRT index)
> -
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
>
[jira] [Commented] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774154#comment-16774154
]
Michael Dürig commented on OAK-8069:
Fixed in trunk at [http://svn.apache.org/viewvc?rev=1854058=rev
|http://svn.apache.org/viewvc?rev=1854058=rev.]
I keep an eye on the benchmarks before proceeding with backporting.
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: TarMK
> Fix For: 1.12, 1.11.0, 1.10.1, 1.8.12
>
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8072) Aggregate jcr:content result nodes as their parent
[ https://issues.apache.org/jira/browse/OAK-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8072: Fix Version/s: 1.12 > Aggregate jcr:content result nodes as their parent > --- > > Key: OAK-8072 > URL: https://issues.apache.org/jira/browse/OAK-8072 > Project: Jackrabbit Oak > Issue Type: Task > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12, 1.11.0 > > > Until the time we'll be able to work on the index time aggregation for Solr, > we should make it possible to aggregate search results of > _/foo/bar/jcr:content_ nodes as their parents _/foo/bar_ as that's what > nowadays often done in Lucene index configuration and therefore useful for > feature parity. > We can disabled this as soon as we switch oak-solr to depend on oak-search > and therefore Solr index gains the index time aggregation feature > consequently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs
[
https://issues.apache.org/jira/browse/OAK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774151#comment-16774151
]
Thomas Mueller commented on OAK-8051:
-
> Actually what's wrong is that if the first attempt to open the map fails, the
> object fill have a null map and will not be in status closed, thus causing an
> NPE when calling get().
Yes, I agree.
> Confusion in itself is problematic
Sure. It's good to get rid of the confusion (NPE log messages, strange
behavior).
I just argue that my patch is slightly better, as it can deal with interrupt
exceptions happening early on. Your patch would fail for this case, breaking
the test case.
> PersistentCache: error during open can lead to incomplete initialization and
> subsequent NPEs
>
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data
> [1.4.193/7]
> at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
> at org.h2.mvstore.FileStore.open(FileStore.java:168)
> at org.h2.mvstore.MVStore.(MVStore.java:348)
> at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the map
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.setRDBConnection(DocumentMK.java:757)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStore(DocumentNodeStoreService.java:508)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStoreIfPossible(DocumentNodeStoreService.java:430)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.activate(DocumentNodeStoreService.java:414)
> {noformat}
> and then
> {noformat}
> 22.01.2019 08:45:16.808 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap
>
[jira] [Commented] (OAK-8067) Measure fsync (called when closing the NRT index)
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774145#comment-16774145
]
Thomas Mueller commented on OAK-8067:
-
http://svn.apache.org/r1854057
> Measure fsync (called when closing the NRT index)
> -
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
>
[jira] [Updated] (OAK-8067) Measure fsync (called when closing the NRT index)
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-8067:
Summary: Measure fsync (called when closing the NRT index) (was: Delete
NRT index before closing to (hopefully) avoid / speed up fsync)
> Measure fsync (called when closing the NRT index)
> -
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
>
[jira] [Updated] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-8071: --- Description: Add logging / monitoring to detect the situation from OAK-8014. > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.11.0, 1.10.1, 1.8.12 > > > Add logging / monitoring to detect the situation from OAK-8014. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8054) RepMembersConflictHandler creates property with wrong type
[
https://issues.apache.org/jira/browse/OAK-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771763#comment-16771763
]
Alex Deparvu edited comment on OAK-8054 at 2/21/19 2:45 PM:
* trunk: fixed with http://svn.apache.org/viewvc?rev=1853868=rev
* 1.10: http://svn.apache.org/viewvc?rev=1854053=rev
was (Author: alex.parvulescu):
fixed with http://svn.apache.org/viewvc?rev=1853868=rev
> RepMembersConflictHandler creates property with wrong type
> --
>
> Key: OAK-8054
> URL: https://issues.apache.org/jira/browse/OAK-8054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Critical
> Labels: candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8054-impact.patch, OAK-8054.patch
>
>
> The {{RepMembersConflictHandler}} handler uses type {{STRING}} instead of
> {{WEAKREFERENCE}} [0] as per the property's definition, which will trigger
> the type validation to fail the commit.
> Running external login tests I see that the type fails as soon as the handler
> comes into play:
> {noformat}
> WARN o.a.j.o.s.s.a.e.i.ExternalLoginModule - User synchronization failed
> during commit: org.apache.jackrabbit.oak.api.CommitFailedException:
> OakConstraint0004:
> /rep:security/rep:authorizables/rep:groups/pathPrefix/g8/rep:membersList/9[[rep:MemberReferences]]:
> No matching property definition found for rep:members =
> [8e490910-17b6-30c1-8e11-6abdfa8a4ebc, 1a8e79f5-428e-39e9-88bb-2b86bd9b402e,
> ... ]. (attempt 10/50)
> {noformat}
> This seems to be a pretty big issue, and I'm not yet sure why it wasn't
> caught by the existing tests.
> // fyi [~anchela]
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/RepMembersConflictHandler.java#L135
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-8014:
---
Priority: Major (was: Blocker)
> Commits carrying over from previous GC generation can block other threads
> from committing
> -
>
> Key: OAK-8014
> URL: https://issues.apache.org/jira/browse/OAK-8014
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.11
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Fix For: 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8014.patch
>
>
> A commit that is based on a previous (full) generation can block other
> commits from progressing for a long time. This happens because such a commit
> will do a deep copy of its state to avoid linking to old segments (see
> OAK-3348). Most of the deep copying is usually avoided by the deduplication
> caches. However, in cases where the cache hit rate is not good enough we have
> seen deep copy operations up to several minutes. Sometimes this deep copy
> operation happens inside the commit lock of
> {{LockBasedScheduler.schedule()}}, which then causes all other commits to
> become blocked.
> cc [~rma61...@adobe.com], [~edivad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774106#comment-16774106
]
Michael Dürig commented on OAK-8069:
{quote}linked list for the path
{quote}
I'd do this if Java had a simple cons list. However for now I'd rather keep it
simple assuming this isn't a performance issue. In any case I'll double check
out benchmark numbers with this patch.
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8072) Aggregate jcr:content result nodes as their parent
[ https://issues.apache.org/jira/browse/OAK-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774130#comment-16774130 ] Tommaso Teofili commented on OAK-8072: -- fixed in r1854055. > Aggregate jcr:content result nodes as their parent > --- > > Key: OAK-8072 > URL: https://issues.apache.org/jira/browse/OAK-8072 > Project: Jackrabbit Oak > Issue Type: Task > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.11.0 > > > Until the time we'll be able to work on the index time aggregation for Solr, > we should make it possible to aggregate search results of > _/foo/bar/jcr:content_ nodes as their parents _/foo/bar_ as that's what > nowadays often done in Lucene index configuration and therefore useful for > feature parity. > We can disabled this as soon as we switch oak-solr to depend on oak-search > and therefore Solr index gains the index time aggregation feature > consequently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
Michael Dürig created OAK-8071: -- Summary: Logging to detect commits carrying over from previous GC generation can block other threads from committing Key: OAK-8071 URL: https://issues.apache.org/jira/browse/OAK-8071 Project: Jackrabbit Oak Issue Type: Technical task Components: segment-tar Reporter: Michael Dürig Assignee: Michael Dürig -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8072) Aggregate jcr:content result nodes as their parent
Tommaso Teofili created OAK-8072: Summary: Aggregate jcr:content result nodes as their parent Key: OAK-8072 URL: https://issues.apache.org/jira/browse/OAK-8072 Project: Jackrabbit Oak Issue Type: Task Components: solr Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.11.0 Until the time we'll be able to work on the index time aggregation for Solr, we should make it possible to aggregate search results of _/foo/bar/jcr:content_ nodes as their parents _/foo/bar_ as that's what nowadays often done in Lucene index configuration and therefore useful for feature parity. We can disabled this as soon as we switch oak-solr to depend on oak-search and therefore Solr index gains the index time aggregation feature consequently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8054) RepMembersConflictHandler creates property with wrong type
[
https://issues.apache.org/jira/browse/OAK-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8054:
--
Fix Version/s: 1.10.1
> RepMembersConflictHandler creates property with wrong type
> --
>
> Key: OAK-8054
> URL: https://issues.apache.org/jira/browse/OAK-8054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Critical
> Labels: candidate_oak_1_10, candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8054-impact.patch, OAK-8054.patch
>
>
> The {{RepMembersConflictHandler}} handler uses type {{STRING}} instead of
> {{WEAKREFERENCE}} [0] as per the property's definition, which will trigger
> the type validation to fail the commit.
> Running external login tests I see that the type fails as soon as the handler
> comes into play:
> {noformat}
> WARN o.a.j.o.s.s.a.e.i.ExternalLoginModule - User synchronization failed
> during commit: org.apache.jackrabbit.oak.api.CommitFailedException:
> OakConstraint0004:
> /rep:security/rep:authorizables/rep:groups/pathPrefix/g8/rep:membersList/9[[rep:MemberReferences]]:
> No matching property definition found for rep:members =
> [8e490910-17b6-30c1-8e11-6abdfa8a4ebc, 1a8e79f5-428e-39e9-88bb-2b86bd9b402e,
> ... ]. (attempt 10/50)
> {noformat}
> This seems to be a pretty big issue, and I'm not yet sure why it wasn't
> caught by the existing tests.
> // fyi [~anchela]
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/RepMembersConflictHandler.java#L135
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8054) RepMembersConflictHandler creates property with wrong type
[
https://issues.apache.org/jira/browse/OAK-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated OAK-8054:
--
Labels: candidate_oak_1_8 (was: candidate_oak_1_10 candidate_oak_1_8)
> RepMembersConflictHandler creates property with wrong type
> --
>
> Key: OAK-8054
> URL: https://issues.apache.org/jira/browse/OAK-8054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Critical
> Labels: candidate_oak_1_8
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8054-impact.patch, OAK-8054.patch
>
>
> The {{RepMembersConflictHandler}} handler uses type {{STRING}} instead of
> {{WEAKREFERENCE}} [0] as per the property's definition, which will trigger
> the type validation to fail the commit.
> Running external login tests I see that the type fails as soon as the handler
> comes into play:
> {noformat}
> WARN o.a.j.o.s.s.a.e.i.ExternalLoginModule - User synchronization failed
> during commit: org.apache.jackrabbit.oak.api.CommitFailedException:
> OakConstraint0004:
> /rep:security/rep:authorizables/rep:groups/pathPrefix/g8/rep:membersList/9[[rep:MemberReferences]]:
> No matching property definition found for rep:members =
> [8e490910-17b6-30c1-8e11-6abdfa8a4ebc, 1a8e79f5-428e-39e9-88bb-2b86bd9b402e,
> ... ]. (attempt 10/50)
> {noformat}
> This seems to be a pretty big issue, and I'm not yet sure why it wasn't
> caught by the existing tests.
> // fyi [~anchela]
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/RepMembersConflictHandler.java#L135
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774119#comment-16774119
]
Michael Dürig commented on OAK-8014:
Filed OAK-8071 to add logging to detect this situation happening.
> Commits carrying over from previous GC generation can block other threads
> from committing
> -
>
> Key: OAK-8014
> URL: https://issues.apache.org/jira/browse/OAK-8014
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.11
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Fix For: 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8014.patch
>
>
> A commit that is based on a previous (full) generation can block other
> commits from progressing for a long time. This happens because such a commit
> will do a deep copy of its state to avoid linking to old segments (see
> OAK-3348). Most of the deep copying is usually avoided by the deduplication
> caches. However, in cases where the cache hit rate is not good enough we have
> seen deep copy operations up to several minutes. Sometimes this deep copy
> operation happens inside the commit lock of
> {{LockBasedScheduler.schedule()}}, which then causes all other commits to
> become blocked.
> cc [~rma61...@adobe.com], [~edivad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8014) Commits carrying over from previous GC generation can block other threads from committing
[
https://issues.apache.org/jira/browse/OAK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-8014:
---
Fix Version/s: (was: 1.12)
1.10.1
> Commits carrying over from previous GC generation can block other threads
> from committing
> -
>
> Key: OAK-8014
> URL: https://issues.apache.org/jira/browse/OAK-8014
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.11
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: TarMK
> Fix For: 1.11.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8014.patch
>
>
> A commit that is based on a previous (full) generation can block other
> commits from progressing for a long time. This happens because such a commit
> will do a deep copy of its state to avoid linking to old segments (see
> OAK-3348). Most of the deep copying is usually avoided by the deduplication
> caches. However, in cases where the cache hit rate is not good enough we have
> seen deep copy operations up to several minutes. Sometimes this deep copy
> operation happens inside the commit lock of
> {{LockBasedScheduler.schedule()}}, which then causes all other commits to
> become blocked.
> cc [~rma61...@adobe.com], [~edivad]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8064) Build Jackrabbit Oak #1960 failed
[ https://issues.apache.org/jira/browse/OAK-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774120#comment-16774120 ] Hudson commented on OAK-8064: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1964|https://builds.apache.org/job/Jackrabbit%20Oak/1964/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1964/console] > Build Jackrabbit Oak #1960 failed > - > > Key: OAK-8064 > URL: https://issues.apache.org/jira/browse/OAK-8064 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1960 has failed. > First failed run: [Jackrabbit Oak > #1960|https://builds.apache.org/job/Jackrabbit%20Oak/1960/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1960/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8071) Logging to detect commits carrying over from previous GC generation can block other threads from committing
[ https://issues.apache.org/jira/browse/OAK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-8071: --- Fix Version/s: 1.8.12 1.10.1 1.11.0 > Logging to detect commits carrying over from previous GC generation can block > other threads from committing > --- > > Key: OAK-8071 > URL: https://issues.apache.org/jira/browse/OAK-8071 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: segment-tar >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Fix For: 1.11.0, 1.10.1, 1.8.12 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-8069:
---
Priority: Blocker (was: Major)
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: TarMK
> Fix For: 1.11.0, 1.10.1, 1.8.12
>
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-8069:
---
Fix Version/s: 1.8.12
1.10.1
1.11.0
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
> Fix For: 1.11.0, 1.10.1, 1.8.12
>
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774053#comment-16774053
]
Michael Dürig commented on OAK-8069:
That maps collect all child nodes of a node that have modifications wrt. its
the base state. Once collected those child nodes are written into a
{{MapRecord}}.
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774046#comment-16774046
]
Axel Hanikel edited comment on OAK-8069 at 2/21/19 12:57 PM:
-
[~mduerig] That looks good to me. Perhaps we could use some sort of a linked
list for the path and defer the string concatenations to the
{{warnOnManyChildren}} function?
What's the purpose of the childNodes map?
was (Author: ahanikel):
[~mduerig] That looks good to me. Perhaps we could use some sort of a linked
list for the path and defer the string concatenations to the
{{warnOnManyChildren}} function?
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774046#comment-16774046
]
Axel Hanikel commented on OAK-8069:
---
[~mduerig] That looks good to me. Perhaps we could use some sort of a linked
list for the path and defer the string concatenations to the
{{warnOnManyChildren}} function?
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8064) Build Jackrabbit Oak #1960 failed
[ https://issues.apache.org/jira/browse/OAK-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774042#comment-16774042 ] Hudson commented on OAK-8064: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1963|https://builds.apache.org/job/Jackrabbit%20Oak/1963/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1963/console] > Build Jackrabbit Oak #1960 failed > - > > Key: OAK-8064 > URL: https://issues.apache.org/jira/browse/OAK-8064 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1960 has failed. > First failed run: [Jackrabbit Oak > #1960|https://builds.apache.org/job/Jackrabbit%20Oak/1960/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1960/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8030) oak-jcr NodeTypeTest improvements
[
https://issues.apache.org/jira/browse/OAK-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8030:
Priority: Minor (was: Major)
> oak-jcr NodeTypeTest improvements
> -
>
> Key: OAK-8030
> URL: https://issues.apache.org/jira/browse/OAK-8030
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0
>
>
> The check for trivial updates could use {{LogCustomizer}} to verify that the
> right thing happens behind the scenes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek resolved OAK-8070. Resolution: Fixed > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.12, 1.6.17, 1.11.0, 1.10.1, 1.8.12 > > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8068: Labels: candidate_oak_1_10 (was: ) > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8070: Fix Version/s: 1.12 > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.12, 1.6.17, 1.11.0, 1.10.1, 1.8.12 > > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774027#comment-16774027 ] Julian Reschke commented on OAK-8068: - trunk: [r1854044|http://svn.apache.org/r1854044] > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-8068. - Resolution: Fixed > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8068: Fix Version/s: 1.11.0 > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12, 1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8033) Node states sometimes refer to more than a single generation of segments after a full compaction
[
https://issues.apache.org/jira/browse/OAK-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8033:
Labels: TarMK candidate_oak_1_6 (was: TarMK candidate_oak_1_10
candidate_oak_1_6 candidate_oak_1_8)
> Node states sometimes refer to more than a single generation of segments
> after a full compaction
>
>
> Key: OAK-8033
> URL: https://issues.apache.org/jira/browse/OAK-8033
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.10.0, 1.8.10, 1.6.16, 1.8.11, 1.10
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK, candidate_oak_1_6
> Fix For: 1.6.17, 1.11.0, 1.10.1, 1.8.12
>
>
> Due to a regression introduced with OAK-7867 a full compaction can sometimes
> cause nodes that are written concurrently to reference segments from more
> than a single gc generation.
> This happens when the {{borrowWriter}} method needs to [create a new
> writer|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBufferWriterPool.java#L197-L201].
> In this case the new writer will be of the generation of the current head
> state instead of the generation associated with the current write operation
> in progress.
>
> cc [~frm], [~ahanikel]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773977#comment-16773977 ] Tomek Rękawek edited comment on OAK-8070 at 2/21/19 11:57 AM: -- Fixed for trunk in [r1854038|https://svn.apache.org/r1854038]. Backported to 1.10 in [r1854040|https://svn.apache.org/r1854040], 1.8 in [r1854039|https://svn.apache.org/r1854039], 1.6 in [r1854043|https://svn.apache.org/r1854043]. was (Author: tomek.rekawek): Fixed for trunk in [r1854038|https://svn.apache.org/r1854038]. Backported to 1.10 in [r1854040|https://svn.apache.org/r1854040], 1.8 in [r1854039|https://svn.apache.org/r1854039]. > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.6.17, 1.11.0, 1.10.1, 1.8.12 > > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773977#comment-16773977 ] Tomek Rękawek edited comment on OAK-8070 at 2/21/19 11:43 AM: -- Fixed for trunk in [r1854038|https://svn.apache.org/r1854038]. Backported to 1.10 in [r1854040|https://svn.apache.org/r1854040], 1.8 in [r1854039|https://svn.apache.org/r1854039]. was (Author: tomek.rekawek): Fixed for trunk in [r1854038|https://svn.apache.org/r1854038]. Backported to 1.8 in [r1854039|https://svn.apache.org/r1854039]. > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.11.0, 1.8.12 > > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-8070: --- Fix Version/s: 1.6.17 > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.6.17, 1.11.0, 1.10.1, 1.8.12 > > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-8070: --- Fix Version/s: 1.10.1 > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.11.0, 1.10.1, 1.8.12 > > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-8070: --- Fix Version/s: 1.8.12 1.11.0 > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > Fix For: 1.11.0, 1.8.12 > > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773977#comment-16773977 ] Tomek Rękawek edited comment on OAK-8070 at 2/21/19 11:22 AM: -- Fixed for trunk in [r1854038|https://svn.apache.org/r1854038]. Backported to 1.8 in [r1854039|https://svn.apache.org/r1854039]. was (Author: tomek.rekawek): Fixed for trunk in [r1854038|https://svn.apache.org/r1854038]. > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7182) Make it possible to update Guava
[ https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773981#comment-16773981 ] Davide Giannella commented on OAK-7182: --- [~rombert] bq. And, in practice, we will only need this for Guava, right? Right now yes. That I'm aware. However it will set a "sustainable" model. If in the feature we found another dependency causing problems integrating in 3rd party products we may add to the shading. I think the most important aspect will be that it will free Oak from intra-dependencies lock-down and in case of security issues here and there we'll be more free to update and keep Oak secure. > Make it possible to update Guava > > > Key: OAK-7182 > URL: https://issues.apache.org/jira/browse/OAK-7182 > Project: Jackrabbit Oak > Issue Type: Wish >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, > OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, > guava.diff > > > We currently rely on Guava 15, and this affects all users of Oak because they > essentially need to use the same version. > This is an overall issue to investigate what would need to be done in Oak in > order to make updates possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8069) Log warning for too many transient modifications of direct child nodes
[
https://issues.apache.org/jira/browse/OAK-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773971#comment-16773971
]
Michael Dürig commented on OAK-8069:
Proposed patch:
[https://github.com/mduerig/jackrabbit-oak/commit/e17c4a8c0619b842e974cb06b3fb487b94c72ece]
[~ahanikel], could you have a look?
> Log warning for too many transient modifications of direct child nodes
> --
>
> Key: OAK-8069
> URL: https://issues.apache.org/jira/browse/OAK-8069
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
>
> In a first step towards resolving OAK-8066, I want to add some logging
> regarding the number of transiently modified direct child nodes in
> {{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773977#comment-16773977 ] Tomek Rękawek commented on OAK-8070: Fixed for trunk in [r1854038|https://svn.apache.org/r1854038]. > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
Tomek Rękawek created OAK-8070: -- Summary: The date-based copy-versions directive doesn't work correctly with include-paths Key: OAK-8070 URL: https://issues.apache.org/jira/browse/OAK-8070 Project: Jackrabbit Oak Issue Type: Bug Components: upgrade Affects Versions: 1.10.0, 1.2.28, 1.8.0, 1.4.19, 1.0.40, 1.6.7 Reporter: Tomek Rękawek It seems that the OAK-6633 introduced a regression. Right now, if the include-paths is used together with a date-based copy-versions, the second copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[ https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek reassigned OAK-8070: -- Assignee: Tomek Rękawek > The date-based copy-versions directive doesn't work correctly with > include-paths > > > Key: OAK-8070 > URL: https://issues.apache.org/jira/browse/OAK-8070 > Project: Jackrabbit Oak > Issue Type: Bug > Components: upgrade >Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek >Priority: Major > > It seems that the OAK-6633 introduced a regression. Right now, if the > include-paths is used together with a date-based copy-versions, the second > copy-versions date is ignored and all the versions are removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8070) The date-based copy-versions directive doesn't work correctly with include-paths
[
https://issues.apache.org/jira/browse/OAK-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773968#comment-16773968
]
Tomek Rękawek commented on OAK-8070:
The OAK-6633 removes all the version-related properties from the versionable
nodes which hasn't been included in the copy-versions. However, because of the
bug, the version histories can't be evaluated correctly. The version storage in
the {{getVersionableNodes()}} is an empty node when the include-paths is used.
> The date-based copy-versions directive doesn't work correctly with
> include-paths
>
>
> Key: OAK-8070
> URL: https://issues.apache.org/jira/browse/OAK-8070
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Affects Versions: 1.6.7, 1.0.40, 1.4.19, 1.8.0, 1.2.28, 1.10.0
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
>
> It seems that the OAK-6633 introduced a regression. Right now, if the
> include-paths is used together with a date-based copy-versions, the second
> copy-versions date is ignored and all the versions are removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8023:
Fix Version/s: 1.10.1
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8023-2.patch, OAK-8023-3.patch, OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773965#comment-16773965
]
angela commented on OAK-8023:
-
[~stillalex], merged fix into 1.10 branch at revision 1854036.
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0, 1.10.1
>
> Attachments: OAK-8023-2.patch, OAK-8023-3.patch, OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8066) Nodes with many direct children can lead to OOME when saving
[
https://issues.apache.org/jira/browse/OAK-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773959#comment-16773959
]
Michael Dürig commented on OAK-8066:
Filed OAK-8069 for adding logging to better understand the situation.
> Nodes with many direct children can lead to OOME when saving
>
>
> Key: OAK-8066
> URL: https://issues.apache.org/jira/browse/OAK-8066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
>
> {{DefaultSegmentWriter}} keeps a map of [child
> nodes|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/DefaultSegmentWriter.java#L805]
> of a node being written. This can lead to high memory consumption in the
> case where many child nodes are added at the same time. The latter could
> happen in the case where a node needs to be rewritten because of an increase
> in the GC generation from a concurrently completed revision garbage
> collection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Moved] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke moved JCR-4417 to OAK-8068: -- Component/s: (was: parent) parent Workflow: no-reopen-closed (was: no-reopen-closed, patch-avail) Key: OAK-8068 (was: JCR-4417) Project: Jackrabbit Oak (was: Jackrabbit Content Repository) > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8068) Update slf4j dependency to 1.7.26
[ https://issues.apache.org/jira/browse/OAK-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8068: Fix Version/s: 1.12 > Update slf4j dependency to 1.7.26 > - > > Key: OAK-8068 > URL: https://issues.apache.org/jira/browse/OAK-8068 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.12 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8069) Log warning for too many transient modifications of direct child nodes
Michael Dürig created OAK-8069:
--
Summary: Log warning for too many transient modifications of
direct child nodes
Key: OAK-8069
URL: https://issues.apache.org/jira/browse/OAK-8069
Project: Jackrabbit Oak
Issue Type: Technical task
Components: segment-tar
Reporter: Michael Dürig
Assignee: Michael Dürig
In a first step towards resolving OAK-8066, I want to add some logging
regarding the number of transiently modified direct child nodes in
{{DefaultSegmentWriter}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773955#comment-16773955
]
Julian Reschke commented on OAK-8052:
-
trunk: [r1854034|http://svn.apache.org/r1854034]
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8052:
Labels: candidate_oak_1_10 candidate_oak_1_6 candidate_oak_1_8 (was:
candidate_oak_1_10 candidate_oak_1_6 candidate_oak_1_8 patch-available)
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-8052.
-
Resolution: Fixed
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_6, candidate_oak_1_8
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8052:
Fix Version/s: 1.11.0
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8064) Build Jackrabbit Oak #1960 failed
[ https://issues.apache.org/jira/browse/OAK-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773923#comment-16773923 ] Hudson commented on OAK-8064: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1962|https://builds.apache.org/job/Jackrabbit%20Oak/1962/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1962/console] > Build Jackrabbit Oak #1960 failed > - > > Key: OAK-8064 > URL: https://issues.apache.org/jira/browse/OAK-8064 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1960 has failed. > First failed run: [Jackrabbit Oak > #1960|https://builds.apache.org/job/Jackrabbit%20Oak/1960/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1960/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8023) AccessControlManagerImpl can not handle repository level when editing policies by principal
[
https://issues.apache.org/jira/browse/OAK-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8023:
Labels: candidate_oak_1_10 (was: )
> AccessControlManagerImpl can not handle repository level when editing
> policies by principal
> ---
>
> Key: OAK-8023
> URL: https://issues.apache.org/jira/browse/OAK-8023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8023-2.patch, OAK-8023-3.patch, OAK-8023.patch
>
>
> [~stillalex], it seems that editing access control by principal in the
> default implementation doesn't allow for applying entries to the 'null' path.
> initially i thought that we can use an empty string value instead for the
> {{rep:nodePath}}, but that doesn't work as it gets converted to "." for some
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8067) Delete NRT index before closing to (hopefully) avoid / speed up fsync
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773889#comment-16773889
]
Thomas Mueller commented on OAK-8067:
-
[~catholicon] could you review the patch please? Not sure if my understanding
is correct...
> Delete NRT index before closing to (hopefully) avoid / speed up fsync
> -
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
> at
> org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
> at
> org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
> at
>
[jira] [Created] (OAK-8067) Delete NRT index before closing to (hopefully) avoid / speed up fsync
Thomas Mueller created OAK-8067:
---
Summary: Delete NRT index before closing to (hopefully) avoid /
speed up fsync
Key: OAK-8067
URL: https://issues.apache.org/jira/browse/OAK-8067
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Thomas Mueller
Assignee: Thomas Mueller
We have seen the following stack trace, and saw that fsync was seemingly very
slow on the system.
Two issues: (1) fsync seems to be very slow here (2) fsync is called while
holding a lock.
(2) should be resolved by lazy-loading indexes.
{noformat}
"oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
java.lang.Thread.State: RUNNABLE
atjava.io.FileDescriptor.sync(Native Method)
at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
at
org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
at
org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
at
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
- locked <0x20595abf> (a java.lang.Object)
at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
- locked <0x20595abf> (a java.lang.Object)
at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
- locked <0x20595abf> (a java.lang.Object)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
at
org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
at
org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
at
org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
- locked <0x85f9b65> (a
org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
at
org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
at
org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
at
org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
at
org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
at
org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
at
org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:147)
at
org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
at
org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compareExisting(JsopNodeStateDiffer.java:100)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.access$000(JsopNodeStateDiffer.java:27)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer$1.childNodeChanged(JsopNodeStateDiffer.java:65)
at
org.apache.jackrabbit.oak.plugins.document.DiffCache.parseJsopDiff(DiffCache.java:118)
at
org.apache.jackrabbit.oak.plugins.document.JsopNodeStateDiffer.compare(JsopNodeStateDiffer.java:51)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1766)
at
org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:113)
at
org.apache.jackrabbit.oak.composite.CompositeNodeState.compareAgainstBaseState(CompositeNodeState.java:163)
[jira] [Commented] (OAK-8067) Delete NRT index before closing to (hopefully) avoid / speed up fsync
[
https://issues.apache.org/jira/browse/OAK-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773882#comment-16773882
]
Thomas Mueller commented on OAK-8067:
-
Proposed patch:
{noformat}
Index:
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/NRTIndex.java
===
---
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/NRTIndex.java
(revision 1853204)
+++
src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/NRTIndex.java
(working copy)
@@ -59,6 +59,9 @@
public class NRTIndex implements Closeable {
+
+private static final boolean REGULAR_CLOSE =
Boolean.getBoolean("oak.lucene.nrt.regularClose");
+
private static final AtomicInteger COUNTER = new AtomicInteger();
private static final Logger log = LoggerFactory.getLogger(NRTIndex.class);
@@ -200,10 +203,25 @@
assertAllReadersAreClosed();
if (indexWriter != null) {
-//TODO Close call can possibly be speeded up by
-//avoiding merge and dropping stuff in memory. To be explored
-//indexWrite.close(waitForMerges)
-indexWriter.close();
+
+long time = System.nanoTime();
+if (REGULAR_CLOSE) {
+indexWriter.close();
+} else {
+// new style: delete all before closing
+indexWriter.deleteAll();
+// don't merge, as anyway we remove the index
+indexWriter.close(false);
+}
+time = System.nanoTime() - time;
+if (time > 100_000_000) {
+// slower than 100 ms
+log.info("Closing time: {} ns", time);
+} else if (log.isTraceEnabled()) {
+log.trace("Closing time: {} ns", time);
+}
+
sizeHisto.update(dirSize(directory));
directory.close();
FileUtils.deleteQuietly(indexDir);
{noformat}
> Delete NRT index before closing to (hopefully) avoid / speed up fsync
> -
>
> Key: OAK-8067
> URL: https://issues.apache.org/jira/browse/OAK-8067
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> We have seen the following stack trace, and saw that fsync was seemingly very
> slow on the system.
> Two issues: (1) fsync seems to be very slow here (2) fsync is called while
> holding a lock.
> (2) should be resolved by lazy-loading indexes.
> {noformat}
> "oak-lucene-22" daemon prio=1 tid=0x6b1 nid=0x runnable
>java.lang.Thread.State: RUNNABLE
> atjava.io.FileDescriptor.sync(Native Method)
> at org.apache.lucene.store.FSDirectory.fsync(FSDirectory.java:505)
> at org.apache.lucene.store.FSDirectory.sync(FSDirectory.java:307)
> at
> org.apache.lucene.store.NRTCachingDirectory.sync(NRTCachingDirectory.java:219)
> at
> org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4489)
> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2953)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3049)
> - locked <0x20595abf> (a java.lang.Object)
> at
> org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1041)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:932)
> - locked <0x20595abf> (a java.lang.Object)
> at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:894)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndex.close(NRTIndex.java:206)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.closeLast(NRTIndexFactory.java:133)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory.createIndex(NRTIndexFactory.java:89)
> - locked <0x85f9b65> (a
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.NRTIndexFactory)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexNodeManager.open(LuceneIndexNodeManager.java:73)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker$1.leave(IndexTracker.java:154)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:152)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeChanged(CompositeNodeState.java:309)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeChanged(CompositeNodeState.java:256)
> at
>
[jira] [Assigned] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-8052:
---
Assignee: Julian Reschke
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8066) Nodes with many direct children can lead to OOME when saving
[
https://issues.apache.org/jira/browse/OAK-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773822#comment-16773822
]
Michael Dürig commented on OAK-8066:
One way to fix this is to regularly flush the accumulated child nodes into a
map record. See [https://github.com/mduerig/jackrabbit-oak/tree/OAK-8066] for
WIP.
/cc [~frm]
> Nodes with many direct children can lead to OOME when saving
>
>
> Key: OAK-8066
> URL: https://issues.apache.org/jira/browse/OAK-8066
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Major
> Labels: TarMK
>
> {{DefaultSegmentWriter}} keeps a map of [child
> nodes|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/DefaultSegmentWriter.java#L805]
> of a node being written. This can lead to high memory consumption in the
> case where many child nodes are added at the same time. The latter could
> happen in the case where a node needs to be rewritten because of an increase
> in the GC generation from a concurrently completed revision garbage
> collection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8066) Nodes with many direct children can lead to OOME when saving
Michael Dürig created OAK-8066:
--
Summary: Nodes with many direct children can lead to OOME when
saving
Key: OAK-8066
URL: https://issues.apache.org/jira/browse/OAK-8066
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Reporter: Michael Dürig
Assignee: Michael Dürig
{{DefaultSegmentWriter}} keeps a map of [child
nodes|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/DefaultSegmentWriter.java#L805]
of a node being written. This can lead to high memory consumption in the case
where many child nodes are added at the same time. The latter could happen in
the case where a node needs to be rewritten because of an increase in the GC
generation from a concurrently completed revision garbage collection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs
[
https://issues.apache.org/jira/browse/OAK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773819#comment-16773819
]
Julian Reschke commented on OAK-8051:
-
bq. It would be better if 10 retries are attempted immediately in the
constructor of CacheMap, instead of later on when trying to use the CacheMap
It probably wouldn't hurt, but also wouldn't have helped in this case (where
the cache file was locked).
> PersistentCache: error during open can lead to incomplete initialization and
> subsequent NPEs
>
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data
> [1.4.193/7]
> at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
> at org.h2.mvstore.FileStore.open(FileStore.java:168)
> at org.h2.mvstore.MVStore.(MVStore.java:348)
> at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the map
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.setRDBConnection(DocumentMK.java:757)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStore(DocumentNodeStoreService.java:508)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStoreIfPossible(DocumentNodeStoreService.java:430)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.activate(DocumentNodeStoreService.java:414)
> {noformat}
> and then
> {noformat}
> 22.01.2019 08:45:16.808 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap
> Re-opening map PREV_DOCUMENT
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.get(CacheMap.java:87)
> at
>
[jira] [Commented] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs
[
https://issues.apache.org/jira/browse/OAK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773818#comment-16773818
]
Julian Reschke commented on OAK-8051:
-
bq. The "error during open can lead to incomplete initialization" is correct,
but incomplete initialization isn't terrible in this case. It's just not nice.
It depends on whether the code is designed to handle this case. Right now this
doesn't seem to be the case.
bq. "subsequent NPEs" is true, however the NPEs are not problematic; they don't
cause failures. They are just confusing.
Confusion in itself is problematic due to people seeing the NPEs and trying to
figure out what is wrong. If the system works as designed, there should be
either no log message, or a log message that is actually readable.
In this case however I see the NPE causing failure to instantiate the
DocumentNodeStore. See second stack trace above.
> PersistentCache: error during open can lead to incomplete initialization and
> subsequent NPEs
>
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data
> [1.4.193/7]
> at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
> at org.h2.mvstore.FileStore.open(FileStore.java:168)
> at org.h2.mvstore.MVStore.(MVStore.java:348)
> at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the map
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.setRDBConnection(DocumentMK.java:757)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStore(DocumentNodeStoreService.java:508)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStoreIfPossible(DocumentNodeStoreService.java:430)
> at
>
[jira] [Commented] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs
[
https://issues.apache.org/jira/browse/OAK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773800#comment-16773800
]
Thomas Mueller commented on OAK-8051:
-
I think the issue description, while technically correct, is misleading:
"PersistentCache: error during open can lead to incomplete initialization and
subsequent NPEs"
The "error during open can lead to incomplete initialization" is correct, but
incomplete initialization isn't terrible in this case. It's just not nice.
"subsequent NPEs" is true, however the NPEs are not problematic; they don't
cause failures. They are just confusing.
> PersistentCache: error during open can lead to incomplete initialization and
> subsequent NPEs
>
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data
> [1.4.193/7]
> at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
> at org.h2.mvstore.FileStore.open(FileStore.java:168)
> at org.h2.mvstore.MVStore.(MVStore.java:348)
> at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the map
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.openMap(CacheMap.java:135)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap.(CacheMap.java:48)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.openMap(PersistentCache.java:468)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.addGeneration(NodeCache.java:115)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.initGenerationCache(PersistentCache.java:452)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.wrap(PersistentCache.java:443)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1214)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildPrevDocumentsCache(DocumentMK.java:1182)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildNodeDocumentCache(DocumentMK.java:1189)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.initialize(RDBDocumentStore.java:798)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:212)
> at
> org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.(RDBDocumentStore.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.setRDBConnection(DocumentMK.java:757)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStore(DocumentNodeStoreService.java:508)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.registerNodeStoreIfPossible(DocumentNodeStoreService.java:430)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.activate(DocumentNodeStoreService.java:414)
> {noformat}
> and then
> {noformat}
> 22.01.2019 08:45:16.808 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.CacheMap
> Re-opening map PREV_DOCUMENT
>
[jira] [Commented] (OAK-8052) PersistentCache: failure during construction may lead to resource leak
[
https://issues.apache.org/jira/browse/OAK-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773804#comment-16773804
]
Thomas Mueller commented on OAK-8052:
-
The patch looks good to me.
> PersistentCache: failure during construction may lead to resource leak
> --
>
> Key: OAK-8052
> URL: https://issues.apache.org/jira/browse/OAK-8052
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8052.diff
>
>
> In the constructor:
> {noformat}
> readGeneration = generations.size() > 1 ? generations.first() : -1;
> writeGeneration = generations.size() > 0 ? generations.last() : 0;
> if (readGeneration >= 0) {
> readStore = createMapFactory(readGeneration, true);
> }
> writeStore = createMapFactory(writeGeneration, false);
> initBroadcast(broadcast);
> {noformat}
> ...so if {{createMapFactory}} fails for {{writeStore}}, {{readStore}} will
> not be closed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8051) PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs
[
https://issues.apache.org/jira/browse/OAK-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773796#comment-16773796
]
Thomas Mueller commented on OAK-8051:
-
As far as I see, your patch is basically just this:
{noformat}
Index:
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/CacheMap.java
public CacheMap(MapFactory factory, String name, Builder builder) {
this.factory = factory;
this.name = name;
this.builder = builder;
openMap();
+if (this.map == null) {
+throw new IllegalStateException("Could not open map for '" + name
+ "'");
+}
}
Index:
oak-store-document/src/test/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/CacheTest.java
@Test
+@Ignore("OAK-8051")
public void recoverIfCorrupt() throws Exception {
FileUtils.deleteDirectory(new File("target/cacheTest"));
new File("target/cacheTest").mkdirs();
{noformat}
The test fails because CacheMap cannot be instantiated.
The idea behind CacheMap reopening attempts is that:
* (A) it tries 10 time to reopen if there was an exception (like: interrupted
exception, caused by Thread.interrupt)
* (B) if reopening failed 10 times, then it goes in a "closed" mode where it's
still usable but doesn't do anything (doesn't cache anything)
Your patch breaks both (A) and (B), in case Thread.interrupt was called
slightly before opening CacheMap.
What's wrong with the current code is that:
* A NPE is logged in CacheMap, which can be confusing
* It would be better if 10 retries are attempted immediately in the constructor
of CacheMap, instead of later on when trying to use the CacheMap
Here a patch that should do this (a test case is needed):
{noformat}
svn diff -x --ignore-all-space
Index:
src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/CacheMap.java
===
---
src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/CacheMap.java
(revision 1853143)
+++
src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/CacheMap.java
(working copy)
@@ -46,7 +46,14 @@
this.name = name;
this.builder = builder;
openMap();
+// OAK-8051: if opening failed, immediately try to re-open,
+// until either the the map is closed, or open
+for (int i = 0; map == null && !closed; i++) {
+if (map == null) {
+reopen(i, null);
}
+}
+}
{noformat}
So the changes are:
* if map is null, retry until either map is not null or it's closed
* no NPE is logged
> PersistentCache: error during open can lead to incomplete initialization and
> subsequent NPEs
>
>
> Key: OAK-8051
> URL: https://issues.apache.org/jira/browse/OAK-8051
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.6
>Reporter: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, patch-available
> Fix For: 1.12
>
> Attachments: OAK-8051.diff
>
>
> Seen in the wild (in 1.6.6):
> {noformat}
> 22.01.2019 08:45:13.153 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the store _path_/cache-4.data
> java.lang.IllegalStateException: The file is locked: nio:_path_/cache-4.data
> [1.4.193/7]
> at org.h2.mvstore.DataUtils.newIllegalStateException(DataUtils.java:765)
> at org.h2.mvstore.FileStore.open(FileStore.java:168)
> at org.h2.mvstore.MVStore.(MVStore.java:348)
> at org.h2.mvstore.MVStore$Builder.open(MVStore.java:2923)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openStore(PersistentCache.java:288)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.createMapFactory(PersistentCache.java:361)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.(PersistentCache.java:210)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getPersistentCache(DocumentMK.java:1232)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.buildCache(DocumentMK.java:1211)
> {noformat}
> Later on:
> {noformat}
> 22.01.2019 08:45:13.155 *WARN* [http-/0.0.0.0:80-3]
> org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory Could
> not open the map
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.openMap(PersistentCache.java:335)
> at
>
[jira] [Resolved] (OAK-8065) AbstractSecurityTest.getAccessControlManager: should use getNamePathMapper() instead of DEFAULT
[
https://issues.apache.org/jira/browse/OAK-8065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-8065.
-
Resolution: Fixed
Fix Version/s: 1.11.0
1.12
> AbstractSecurityTest.getAccessControlManager: should use getNamePathMapper()
> instead of DEFAULT
> ---
>
> Key: OAK-8065
> URL: https://issues.apache.org/jira/browse/OAK-8065
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.12, 1.11.0
>
>
> [~stillalex], when writing tests with remapped namespaces i noticed that
> {{AbstractSecurityTest.getAccessControlManager}} does not create an
> {{AccessControlManager}} with the remapping.
> Instead of create the manager with {{NamePathMapper.DEFAULT}} it should use
> {{getNamePathMapper()}}. Will make the change and commit if all tests pass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
