[jira] [Resolved] (OAK-9796) oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor (Apple M1)
[ https://issues.apache.org/jira/browse/OAK-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-9796. --- Fix Version/s: 1.60.0 (was: 1.42.0) (was: 1.22.11) Resolution: Fixed Both PRs are now merged. Resolving this issue. > oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor > (Apple M1) > - > > Key: OAK-9796 > URL: https://issues.apache.org/jira/browse/OAK-9796 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws >Reporter: Thomas Mueller >Priority: Major > Labels: arm > Fix For: 1.60.0 > > > I'm can't build oak-segment-remote with my new laptop (Apple M1 chip) due to > https://github.com/kstyrc/embedded-redis/issues/51 - looks like > https://github.com/kstyrc/embedded-redis is used, which uses an ancient > version of Redis. > There is a fork of https://github.com/kstyrc/embedded-redis that seems more > up-to-date: https://github.com/ozimov/embedded-redis. The last commit there > was in 2020. The issue https://github.com/kstyrc/embedded-redis/issues/51 was > fixed a bit later. So switching to that embedded Redis version doesn't > resolve the issue either. > If Redis isn't available, then the test shouldn't fail... instead, the test > should be skipped. this is what we do for mongodb: if it isn't available, > then those tests are not run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9796) oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor (Apple M1)
[ https://issues.apache.org/jira/browse/OAK-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787951#comment-17787951 ] Marcel Reutegger commented on OAK-9796: --- Merged [#1218|https://github.com/apache/jackrabbit-oak/pull/1218]. Created a new PR that skips the test if Redis cannot be started: https://github.com/apache/jackrabbit-oak/pull/1221 > oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor > (Apple M1) > - > > Key: OAK-9796 > URL: https://issues.apache.org/jira/browse/OAK-9796 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws >Reporter: Thomas Mueller >Priority: Major > Labels: arm > Fix For: 1.42.0, 1.22.11 > > > I'm can't build oak-segment-remote with my new laptop (Apple M1 chip) due to > https://github.com/kstyrc/embedded-redis/issues/51 - looks like > https://github.com/kstyrc/embedded-redis is used, which uses an ancient > version of Redis. > There is a fork of https://github.com/kstyrc/embedded-redis that seems more > up-to-date: https://github.com/ozimov/embedded-redis. The last commit there > was in 2020. The issue https://github.com/kstyrc/embedded-redis/issues/51 was > fixed a bit later. So switching to that embedded Redis version doesn't > resolve the issue either. > If Redis isn't available, then the test shouldn't fail... instead, the test > should be skipped. this is what we do for mongodb: if it isn't available, > then those tests are not run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9796) oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor (Apple M1)
[ https://issues.apache.org/jira/browse/OAK-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786708#comment-17786708 ] Marcel Reutegger commented on OAK-9796: --- PersistentRedisCacheTest now also fails on Mac OS Sonoma with Intel processor. Proposed fix switches to a more recent version/fork of embedded-redis: https://github.com/apache/jackrabbit-oak/pull/1218 > oak-segment-remote and oak-segment-aws Redis tests fail with ARM processor > (Apple M1) > - > > Key: OAK-9796 > URL: https://issues.apache.org/jira/browse/OAK-9796 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws >Reporter: Thomas Mueller >Priority: Major > Labels: arm > Fix For: 1.42.0, 1.22.11 > > > I'm can't build oak-segment-remote with my new laptop (Apple M1 chip) due to > https://github.com/kstyrc/embedded-redis/issues/51 - looks like > https://github.com/kstyrc/embedded-redis is used, which uses an ancient > version of Redis. > There is a fork of https://github.com/kstyrc/embedded-redis that seems more > up-to-date: https://github.com/ozimov/embedded-redis. The last commit there > was in 2020. The issue https://github.com/kstyrc/embedded-redis/issues/51 was > fixed a bit later. So switching to that embedded Redis version doesn't > resolve the issue either. > If Redis isn't available, then the test shouldn't fail... instead, the test > should be skipped. this is what we do for mongodb: if it isn't available, > then those tests are not run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10514) Utility method to remove unmerged branch changes
[ https://issues.apache.org/jira/browse/OAK-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10514. Fix Version/s: 1.60.0 Resolution: Fixed Merged the PR. > Utility method to remove unmerged branch changes > > > Key: OAK-10514 > URL: https://issues.apache.org/jira/browse/OAK-10514 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.60.0 > > > Work on detailed revision garbage collection is still in progress. Until this > is finished a utility method in oak-mongo.js would be useful to remove > unmerged branch changes on a document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10514) Utility method to remove unmerged branch changes
[ https://issues.apache.org/jira/browse/OAK-10514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1330#comment-1330 ] Marcel Reutegger commented on OAK-10514: Proposed implementation: https://github.com/apache/jackrabbit-oak/pull/1173 > Utility method to remove unmerged branch changes > > > Key: OAK-10514 > URL: https://issues.apache.org/jira/browse/OAK-10514 > Project: Jackrabbit Oak > Issue Type: Task > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > Work on detailed revision garbage collection is still in progress. Until this > is finished a utility method in oak-mongo.js would be useful to remove > unmerged branch changes on a document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10514) Utility method to remove unmerged branch changes
Marcel Reutegger created OAK-10514: -- Summary: Utility method to remove unmerged branch changes Key: OAK-10514 URL: https://issues.apache.org/jira/browse/OAK-10514 Project: Jackrabbit Oak Issue Type: Task Components: run Reporter: Marcel Reutegger Assignee: Marcel Reutegger Work on detailed revision garbage collection is still in progress. Until this is finished a utility method in oak-mongo.js would be useful to remove unmerged branch changes on a document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10499) Node bundling may resurrect node
[ https://issues.apache.org/jira/browse/OAK-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776263#comment-17776263 ] Marcel Reutegger commented on OAK-10499: Created a draft PR with an ignored test that reproduces the issue: https://github.com/apache/jackrabbit-oak/pull/1160 > Node bundling may resurrect node > > > Key: OAK-10499 > URL: https://issues.apache.org/jira/browse/OAK-10499 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Marcel Reutegger >Priority: Major > > In some cases the DocumentNodeStore node bundling features may resurrect > nodes that have been deleted. The issue happens when the following conditions > are met: > - The repository contains a node structure with bundled nodes > - There is a non-bundled node below a bundled node > - The node structure is removed with a clusterId different from the one used > when the nodes were created > - The node structure is partially re-created with a primary type that is not > configured for node bundling and with a clusterId different from the one used > when the nodes were removed. > After this sequence the non-bundled descendant node is resurrected, even > though it was not recreated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10499) Node bundling may resurrect node
[ https://issues.apache.org/jira/browse/OAK-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10499: --- Description: In some cases the DocumentNodeStore node bundling features may resurrect nodes that have been deleted. The issue happens when the following conditions are met: - The repository contains a node structure with bundled nodes - There is a non-bundled node below a bundled node - The node structure is removed with a clusterId different from the one used when the nodes were created - The node structure is partially re-created with a primary type that is not configured for node bundling and with a clusterId different from the one used when the nodes were removed. After this sequence the non-bundled descendant node is resurrected, even though it was not recreated. was: In some cases the DocumentNodeStore node bundling features may resurrect nodes that have been deleted. The issue happens when the following conditions are met: - The repository contains a node structure with bundled nodes - There is a non-bundled node below a bundled node - The node structure is removed with a clusterId different from the one used when the nodes were created - The node structure is partially re-created with a primary type that is not configured for node bundling and with a clusterId different from the one used when the nodes were removed. After this sequence the non-bundled descendant node is resurrected, even though it was not recreated. > Node bundling may resurrect node > > > Key: OAK-10499 > URL: https://issues.apache.org/jira/browse/OAK-10499 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Reporter: Marcel Reutegger >Priority: Major > > In some cases the DocumentNodeStore node bundling features may resurrect > nodes that have been deleted. The issue happens when the following conditions > are met: > - The repository contains a node structure with bundled nodes > - There is a non-bundled node below a bundled node > - The node structure is removed with a clusterId different from the one used > when the nodes were created > - The node structure is partially re-created with a primary type that is not > configured for node bundling and with a clusterId different from the one used > when the nodes were removed. > After this sequence the non-bundled descendant node is resurrected, even > though it was not recreated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10499) Node bundling may resurrect node
Marcel Reutegger created OAK-10499: -- Summary: Node bundling may resurrect node Key: OAK-10499 URL: https://issues.apache.org/jira/browse/OAK-10499 Project: Jackrabbit Oak Issue Type: Bug Components: documentmk Reporter: Marcel Reutegger In some cases the DocumentNodeStore node bundling features may resurrect nodes that have been deleted. The issue happens when the following conditions are met: - The repository contains a node structure with bundled nodes - There is a non-bundled node below a bundled node - The node structure is removed with a clusterId different from the one used when the nodes were created - The node structure is partially re-created with a primary type that is not configured for node bundling and with a clusterId different from the one used when the nodes were removed. After this sequence the non-bundled descendant node is resurrected, even though it was not recreated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9922) segment-tar: parallel compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773168#comment-17773168 ] Marcel Reutegger commented on OAK-9922: --- bq. I believe this is undesirable I agree. oak-core makes use of the NodeStore API in oak-store-spi and oak-segment-tar is an implementation of this API. It doesn't yet introduce a cyclic dependency, but reduces room for manoeuvre. > segment-tar: parallel compaction > > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.58.0 > > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10432) DocumentStoreIndexerIT failures
[
https://issues.apache.org/jira/browse/OAK-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-10432:
---
Priority: Major (was: Minor)
These tests are still failing. Recent failures I noticed
https://ci-builds.apache.org/blue/organizations/jenkins/Jackrabbit%2Foak-trunk-pr/detail/issue%2Foak-10377/2/pipeline
I think the test should either be fixed or disabled.
> DocumentStoreIndexerIT failures
> ---
>
> Key: OAK-10432
> URL: https://issues.apache.org/jira/browse/OAK-10432
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Marcel Reutegger
>Assignee: Mohit Kataria
>Priority: Major
>
> Tests related to parallel indexing in DocumentStoreIndexerIT fail frequently
> on Jenkins. Output from recent failures:
> {noformat}
> [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed:
> 123.584 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [ERROR]
> parallelReindex(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT) Time
> elapsed: 33.292 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindex(DocumentStoreIndexerIT.java:176)
> ...
> [ERROR]
> parallelReindexWithLZ4(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
> Time elapsed: 29.313 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexWithLZ4(DocumentStoreIndexerIT.java:184)
> {noformat}
> See also previously reported issue OAK-10381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10371) oak-segment-azure/oak-blob-cloud-azure require provided Guava, embed it instead
[ https://issues.apache.org/jira/browse/OAK-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764034#comment-17764034 ] Marcel Reutegger commented on OAK-10371: bq. Why can't you replace the component annotations in just this project? I tried that, but then the generated org.apache.jackrabbit.oak.plugins.blob.datastore.AzureDataStore.xml does not contain a reference to StatisticsProvider. I assume this is because we disabled the SCR plugin and the StatisticsProvider reference is in base class AbstractDataStoreService (in a different bundle) using SCR annotations. > oak-segment-azure/oak-blob-cloud-azure require provided Guava, embed it > instead > --- > > Key: OAK-10371 > URL: https://issues.apache.org/jira/browse/OAK-10371 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob-cloud-azure, segment-azure >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Critical > > These components require Guava due to their dependency on > microsoft-azure-keyvault-core. That dependency is embedded, but Guava is not. > Choices: > - get microsoft-azure-keyvault-core fixed not to use Guava (unlikely, but see > https://github.com/Azure/azure-sdk-for-java/issues/26846) > - embed Guava > - make sure that the OSGi import statement is as relaxed as possible (note > that, for historic reasons, our components for now are likely used in > environments using Guava 15) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10432) DocumentStoreIndexerIT failures
[
https://issues.apache.org/jira/browse/OAK-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-10432:
--
Assignee: Mohit Kataria
[~tihom88], assigning this to you because you worked on OAK-10381.
> DocumentStoreIndexerIT failures
> ---
>
> Key: OAK-10432
> URL: https://issues.apache.org/jira/browse/OAK-10432
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Marcel Reutegger
>Assignee: Mohit Kataria
>Priority: Minor
>
> Tests related to parallel indexing in DocumentStoreIndexerIT fail frequently
> on Jenkins. Output from recent failures:
> {noformat}
> [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed:
> 123.584 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [ERROR]
> parallelReindex(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT) Time
> elapsed: 33.292 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindex(DocumentStoreIndexerIT.java:176)
> ...
> [ERROR]
> parallelReindexWithLZ4(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
> Time elapsed: 29.313 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
> at
> org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexWithLZ4(DocumentStoreIndexerIT.java:184)
> {noformat}
> See also previously reported issue OAK-10381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762585#comment-17762585
]
Marcel Reutegger commented on OAK-10413:
Created OAK-10432.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-10413.
Fix Version/s: 1.58.0
Resolution: Fixed
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.58.0
>
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10432) DocumentStoreIndexerIT failures
Marcel Reutegger created OAK-10432:
--
Summary: DocumentStoreIndexerIT failures
Key: OAK-10432
URL: https://issues.apache.org/jira/browse/OAK-10432
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-run
Reporter: Marcel Reutegger
Tests related to parallel indexing in DocumentStoreIndexerIT fail frequently on
Jenkins. Output from recent failures:
{noformat}
[ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 123.584
s <<< FAILURE! - in org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
[ERROR] parallelReindex(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
Time elapsed: 33.292 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertFalse(Assert.java:65)
at org.junit.Assert.assertFalse(Assert.java:75)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindex(DocumentStoreIndexerIT.java:176)
...
[ERROR]
parallelReindexWithLZ4(org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT)
Time elapsed: 29.313 s <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertFalse(Assert.java:65)
at org.junit.Assert.assertFalse(Assert.java:75)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexInternal(DocumentStoreIndexerIT.java:265)
at
org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT.parallelReindexWithLZ4(DocumentStoreIndexerIT.java:184)
{noformat}
See also previously reported issue OAK-10381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762583#comment-17762583
]
Marcel Reutegger commented on OAK-10413:
It is failing, but at least not hanging anymore as reported in this issue. The
test failures were also reported in OAK-10381, but it doesn't look like the
test issue is fixed. I'm going to create a new issue, because OAK-10381 was
resolved and marked fixed in 1.56.0, which is already released.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762065#comment-17762065
]
Marcel Reutegger commented on OAK-10413:
PR #1099 (including changes from OAK-10427) ran all tests successfully. I
merged the changes into trunk. Let's wait for some more runs until we resolve
this issue.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10428) UserPrincipalProvider updates group cache on every login
[
https://issues.apache.org/jira/browse/OAK-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761997#comment-17761997
]
Marcel Reutegger edited comment on OAK-10428 at 9/5/23 9:08 AM:
bq. In case a group membership cache is stored at the principal, some
properties are updated on every access, and committed.
I noticed this as well in some cases, but the cache is not updated on every
access. There is still a problematic pattern in my view. Once the cache for a
principal reaches the end of its TTL, there is a thundering herd problem.
Multiple requests coming in at roughly the same time will all try to update the
cache and most of them will run into conflicts.
I think it would be better if only one thread updates the cache, while all
other just use the slightly outdated value currently in the cache.
was (Author: mreutegg):
bq. In case a group membership cache is stored at the principal, some
properties are updated on every access, and committed.
I noticed this as well in some cases, but the cache is not updated on every
access. There is still a problematic pattern in my view. Once the cache for a
principal reaches the end of its TTL, there is a thundering herd problem.
Multiple requests coming in at roughly the same time will all try to update the
cache and most of them will run into conflicts.
> UserPrincipalProvider updates group cache on every login
>
>
> Key: OAK-10428
> URL: https://issues.apache.org/jira/browse/OAK-10428
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: authorization-principalbased
>Affects Versions: 1.56.0
>Reporter: Joerg Hoh
>Priority: Major
>
> Under traffic (by a single user) I see in a DocumentNodeStore setup this
> stacktrace for a lot of requests:
> {noformat}
> "qtp2052801890-41390" #41390 prio=5 os_prio=0 cpu=19882.72ms elapsed=3024.20s
> tid=0x564321465800 nid=0x3ec2a waiting on condition [0x7f633f55f000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)
> - parking to wait for <0x0006a0cac5f0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.15/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.15/AbstractQueuedSynchronizer.java:917)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.15/AbstractQueuedSynchronizer.java:1240)
> at
> java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.15/ReentrantLock.java:267)
> at
> org.apache.jackrabbit.oak.plugins.document.locks.StripedNodeDocumentLocks.acquire(StripedNodeDocumentLocks.java:39)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndModify(MongoDocumentStore.java:1054)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndUpdate(MongoDocumentStore.java:1610)
> at
> org.apache.jackrabbit.oak.plugins.document.util.LeaseCheckDocumentStoreWrapper.findAndUpdate(LeaseCheckDocumentStoreWrapper.java:151)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.markCommitRoot(Collision.java:201)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.mark(Collision.java:85)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:604)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:642)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:372)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStoreWithTiming(Commit.java:278)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:262)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:236)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.apply(Commit.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:321)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:283)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:553)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:197)
> at
>
[jira] [Commented] (OAK-10428) UserPrincipalProvider updates group cache on every login
[
https://issues.apache.org/jira/browse/OAK-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761997#comment-17761997
]
Marcel Reutegger commented on OAK-10428:
bq. In case a group membership cache is stored at the principal, some
properties are updated on every access, and committed.
I noticed this as well in some cases, but the cache is not updated on every
access. There is still a problematic pattern in my view. Once the cache for a
principal reaches the end of its TTL, there is a thundering herd problem.
Multiple requests coming in at roughly the same time will all try to update the
cache and most of them will run into conflicts.
> UserPrincipalProvider updates group cache on every login
>
>
> Key: OAK-10428
> URL: https://issues.apache.org/jira/browse/OAK-10428
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: authorization-principalbased
>Affects Versions: 1.56.0
>Reporter: Joerg Hoh
>Priority: Major
>
> Under traffic (by a single user) I see in a DocumentNodeStore setup this
> stacktrace for a lot of requests:
> {noformat}
> "qtp2052801890-41390" #41390 prio=5 os_prio=0 cpu=19882.72ms elapsed=3024.20s
> tid=0x564321465800 nid=0x3ec2a waiting on condition [0x7f633f55f000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.15/Native Method)
> - parking to wait for <0x0006a0cac5f0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.15/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.15/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.15/AbstractQueuedSynchronizer.java:917)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.15/AbstractQueuedSynchronizer.java:1240)
> at
> java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.15/ReentrantLock.java:267)
> at
> org.apache.jackrabbit.oak.plugins.document.locks.StripedNodeDocumentLocks.acquire(StripedNodeDocumentLocks.java:39)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndModify(MongoDocumentStore.java:1054)
> at
> org.apache.jackrabbit.oak.plugins.document.mongo.MongoDocumentStore.findAndUpdate(MongoDocumentStore.java:1610)
> at
> org.apache.jackrabbit.oak.plugins.document.util.LeaseCheckDocumentStoreWrapper.findAndUpdate(LeaseCheckDocumentStoreWrapper.java:151)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.markCommitRoot(Collision.java:201)
> at
> org.apache.jackrabbit.oak.plugins.document.Collision.mark(Collision.java:85)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:604)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.checkConflicts(Commit.java:642)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:372)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStoreWithTiming(Commit.java:278)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToDocumentStore(Commit.java:262)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyInternal(Commit.java:236)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.apply(Commit.java:224)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:321)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.persist(DocumentNodeStoreBranch.java:283)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:553)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:197)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:121)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:170)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:2067)
> at
> org.apache.jackrabbit.oak.composite.CompositeNodeStore.merge(CompositeNodeStore.java:153)
> at
> org.apache.jackrabbit.oak.core.MutableRoot.commit(MutableRoot.java:262)
> at
> org.apache.jackrabbit.oak.security.user.UserPrincipalProvider.cacheGroups(UserPrincipalProvider.java:318)
> at
>
[jira] [Commented] (OAK-10425) Ability to remove mixin type without read permission on jcr:mixinTypes property
[ https://issues.apache.org/jira/browse/OAK-10425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761968#comment-17761968 ] Marcel Reutegger commented on OAK-10425: https://github.com/apache/jackrabbit-oak/pull/1100 adds an ignored test. > Ability to remove mixin type without read permission on jcr:mixinTypes > property > --- > > Key: OAK-10425 > URL: https://issues.apache.org/jira/browse/OAK-10425 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Marcel Reutegger >Priority: Minor > > When a session does not have read permission on property jcr:mixinTypes, then > Node.removeMixin(String) will fail with an exception. This is inconsistent > with other behaviour related to node type information. See OAK-2441 and > OAK-10334. > The call should succeed if the session has permission to write jcr:mixinTypes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10427) Clear cache on NodeDocumentCache close
[ https://issues.apache.org/jira/browse/OAK-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10427. Fix Version/s: 1.58.0 Resolution: Fixed Merged the PR. > Clear cache on NodeDocumentCache close > -- > > Key: OAK-10427 > URL: https://issues.apache.org/jira/browse/OAK-10427 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.58.0 > > > The in-memory caches in NodeDocumentCache are currently not cleared on close > and a referenced NodeDocumentCache instance may still retain significant > memory after close. > In-memory caches should be cleared on close. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10334. Fix Version/s: 1.58.0 Resolution: Fixed Merged the PR. > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.58.0 > > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761867#comment-17761867
]
Marcel Reutegger commented on OAK-10413:
Proposed changes to PurgeOldIndexVersionIT:
https://github.com/apache/jackrabbit-oak/pull/1099
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10427) Clear cache on NodeDocumentCache close
[ https://issues.apache.org/jira/browse/OAK-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761866#comment-17761866 ] Marcel Reutegger commented on OAK-10427: Proposed changes in https://github.com/apache/jackrabbit-oak/pull/1098 > Clear cache on NodeDocumentCache close > -- > > Key: OAK-10427 > URL: https://issues.apache.org/jira/browse/OAK-10427 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The in-memory caches in NodeDocumentCache are currently not cleared on close > and a referenced NodeDocumentCache instance may still retain significant > memory after close. > In-memory caches should be cleared on close. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761865#comment-17761865
]
Marcel Reutegger commented on OAK-10413:
See OAK-10427 for the changes related to MongoDocumentStore. The actual change
is in NodeDocumentCache.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10427) Clear cache on NodeDocumentCache close
Marcel Reutegger created OAK-10427: -- Summary: Clear cache on NodeDocumentCache close Key: OAK-10427 URL: https://issues.apache.org/jira/browse/OAK-10427 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger The in-memory caches in NodeDocumentCache are currently not cleared on close and a referenced NodeDocumentCache instance may still retain significant memory after close. In-memory caches should be cleared on close. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761864#comment-17761864
]
Marcel Reutegger commented on OAK-10413:
Looks like there is not much that can be done about FlatFileStore instances.
There is a list of FlatFileStore created by one of the tests with 24 instances.
The CachingSegmentReader are opened by Persistence used in
PurgeOldIndexVersionIT. The tests in there do not close Persistence in some
cases.
The MongoDocumentStore instances are actually closed, but referenced by
TraverseWithSortStrategy.MemoryListener. This (non-static) inner class
indirectly references a MongoDocumentStore. These listeners are added but never
removed from the MemoryMXBean. A quick fix would be to reduce memory of closed
MongoDocumentStore instances. Currently they are quite heavy weight because
caches they reference are not cleared on close/dispose.
With the two changes mentioned above, I can reliable run oak-run integration
tests in the sequence seen on Jenkins without a memory issue.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761793#comment-17761793
]
Marcel Reutegger commented on OAK-10413:
The majority of memory is occupied by:
- 26 instances of FlatFileStore (144 MB)
- 6 instances of CachingSegmentReader (61 MB)
- 7 instances of MongoDocumentStore (44 MB)
I suspect some tests are not releasing resources.
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10413) DocumentStoreIndexerIT hanging
[
https://issues.apache.org/jira/browse/OAK-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761775#comment-17761775
]
Marcel Reutegger commented on OAK-10413:
I'm able to reproduce when running tests in the same sequence like Jenkins
does. Added the following test and then specified it on the command line with
-Dtest=MyTest.
{noformat}
@RunWith(Suite.class)
@Suite.SuiteClasses({
PurgeOldIndexVersionIT.class,
LuceneIndexCommandIT.class,
ReindexIT.class,
DocumentStoreIndexerIT.class
})
public class MyTest {
}
{noformat}
Analyzing the heap dump...
> DocumentStoreIndexerIT hanging
> --
>
> Key: OAK-10413
> URL: https://issues.apache.org/jira/browse/OAK-10413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, run
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] Running org.apache.jackrabbit.oak.index.DocumentStoreIndexerIT
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file
> /home/jenkins/jenkins-agent/workspace/Jackrabbit/jackrabbit-oak-trunk/oak-run/target/failsafe-reports/2023-08-22T13-46-32_129-jvmRun1.dumpstream
> {noformat}
> ...and then eventually times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761702#comment-17761702 ] Marcel Reutegger commented on OAK-10334: Follow up issue regarding Node.removeMixin(String): OAK-10425 > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10425) Ability to remove mixin type without read permission on jcr:mixinTypes property
[ https://issues.apache.org/jira/browse/OAK-10425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10425: --- Component/s: jcr Description: When a session does not have read permission on property jcr:mixinTypes, then Node.removeMixin(String) will fail with an exception. This is inconsistent with other behaviour related to node type information. See OAK-2441 and OAK-10334. The call should succeed if the session has permission to write jcr:mixinTypes. Summary: Ability to remove mixin type without read permission on jcr:mixinTypes property (was: Ail) > Ability to remove mixin type without read permission on jcr:mixinTypes > property > --- > > Key: OAK-10425 > URL: https://issues.apache.org/jira/browse/OAK-10425 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: jcr >Reporter: Marcel Reutegger >Priority: Minor > > When a session does not have read permission on property jcr:mixinTypes, then > Node.removeMixin(String) will fail with an exception. This is inconsistent > with other behaviour related to node type information. See OAK-2441 and > OAK-10334. > The call should succeed if the session has permission to write jcr:mixinTypes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10425) Ail
Marcel Reutegger created OAK-10425: -- Summary: Ail Key: OAK-10425 URL: https://issues.apache.org/jira/browse/OAK-10425 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Marcel Reutegger -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10266) ClientIpFilterTest fails for localhost
[
https://issues.apache.org/jira/browse/OAK-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760757#comment-17760757
]
Marcel Reutegger commented on OAK-10266:
With the following patch the test runs fine on my machine.
{noformat}
diff --git a/oak-parent/pom.xml b/oak-parent/pom.xml
index 6985e10fa3..b5af63b554 100644
--- a/oak-parent/pom.xml
+++ b/oak-parent/pom.xml
@@ -36,7 +36,7 @@
3.3.9
-Xmx512m
-${test.opts.coverage} ${test.opts.memory}
-XX:+HeapDumpOnOutOfMemoryError -Dupdate.limit=100
-Djava.awt.headless=true
+${test.opts.coverage} ${test.opts.memory}
-XX:+HeapDumpOnOutOfMemoryError -Dupdate.limit=100 -Djava.awt.headless=true
-Djava.net.preferIPv4Stack=true
false
true
0.0
{noformat}
But I rather think the test itself should be somehow improved to work on either
IP stack.
> ClientIpFilterTest fails for localhost
> --
>
> Key: OAK-10266
> URL: https://issues.apache.org/jira/browse/OAK-10266
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Marcel Reutegger
>Priority: Minor
>
> ClientIpFilterTest fails on my machine for filters=localhost.
> The JVM returns an IP v6 address, which does not match the expected 127.0.0.1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10357) Path option for documentstore-check
[ https://issues.apache.org/jira/browse/OAK-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10357. Fix Version/s: 1.56.0 Resolution: Fixed Merged the PR. > Path option for documentstore-check > --- > > Key: OAK-10357 > URL: https://issues.apache.org/jira/browse/OAK-10357 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.56.0 > > > The documentstore-check currently goes through the entire document store. Add > a path option that allows specifying paths to check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758860#comment-17758860 ] Marcel Reutegger commented on OAK-10334: Based on review feedback in the PR the proposed fix now correctly updates jcr:mixinTypes even when the session does not have read permission on the property. This is consistent with the behaviour described in OAK-2441. > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-10334: -- Assignee: Marcel Reutegger > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10304) log registration of invalid namespace names
[
https://issues.apache.org/jira/browse/OAK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757305#comment-17757305
]
Marcel Reutegger commented on OAK-10304:
I would rather keep it simple and backport the code as is. If the log message
is too noisy for some users, they can disable the logger by configuration.
> log registration of invalid namespace names
> ---
>
> Key: OAK-10304
> URL: https://issues.apache.org/jira/browse/OAK-10304
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Labels: candidate_oak_1_22
> Fix For: 1.54.0
>
>
> Example:
> {noformat}
> diff --git
> a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> index f113e4e0d2..7178a36f7f 100644
> --- a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> +++ b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> @@ -1996,6 +1996,24 @@ public class RepositoryTest extends
> AbstractRepositoryTest {
> assertFalse(asList(nsReg.getURIs()).contains("file:///foo"));
> }
> +@Test
> +public void testNamespaceNames() throws RepositoryException {
> +NamespaceRegistry nsReg =
> +getAdminSession().getWorkspace().getNamespaceRegistry();
> +
> +// valid
> +nsReg.registerNamespace("foo", "https://example.com;);
> +nsReg.unregisterNamespace("foo");
> +
> +// invalid
> +try {
> +nsReg.registerNamespace("foo", "example.com");
> +fail("should not register invalid namespace name");
> +} finally {
> +nsReg.unregisterNamespace("foo");
> +}
> +}
> {noformat}
> Note that name of nodes using invalid namespaces do have a valid "expanded
> form" variant
> (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10357) Path option for documentstore-check
[ https://issues.apache.org/jira/browse/OAK-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744189#comment-17744189 ] Marcel Reutegger commented on OAK-10357: Proposed changes in PR: https://github.com/apache/jackrabbit-oak/pull/1031 > Path option for documentstore-check > --- > > Key: OAK-10357 > URL: https://issues.apache.org/jira/browse/OAK-10357 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > > The documentstore-check currently goes through the entire document store. Add > a path option that allows specifying paths to check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10357) Path option for documentstore-check
Marcel Reutegger created OAK-10357: -- Summary: Path option for documentstore-check Key: OAK-10357 URL: https://issues.apache.org/jira/browse/OAK-10357 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Marcel Reutegger Assignee: Marcel Reutegger The documentstore-check currently goes through the entire document store. Add a path option that allows specifying paths to check. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10340) Child order not updated on source after move
[ https://issues.apache.org/jira/browse/OAK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10340. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR into trunk. > Child order not updated on source after move > > > Key: OAK-10340 > URL: https://issues.apache.org/jira/browse/OAK-10340 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > The hidden child order property on the source parent of a move operation is > not updated when the moved node was orderable under the source parent. > The issue does not seem serious, because AbstractTree.getChildNames() is > quite lenient and will add children not present in :childOrder at the end of > the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10340) Child order not updated on source after move
[ https://issues.apache.org/jira/browse/OAK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741510#comment-17741510 ] Marcel Reutegger commented on OAK-10340: The pull request also fixes another issue in MutableTree.moveTo(). The call to the underlying NodeBuilder.moveTo() may returns false. In this case, the MutableTree must not change state, but it currently does. It incorrectly changes its parent to the move target already before NodeBuilder.moveTo(). I added a test that exercises this scenario. > Child order not updated on source after move > > > Key: OAK-10340 > URL: https://issues.apache.org/jira/browse/OAK-10340 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The hidden child order property on the source parent of a move operation is > not updated when the moved node was orderable under the source parent. > The issue does not seem serious, because AbstractTree.getChildNames() is > quite lenient and will add children not present in :childOrder at the end of > the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10340) Child order not updated on source after move
[ https://issues.apache.org/jira/browse/OAK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740203#comment-17740203 ] Marcel Reutegger commented on OAK-10340: Test to reproduce the issue and proposed changes in PR https://github.com/apache/jackrabbit-oak/pull/1017 > Child order not updated on source after move > > > Key: OAK-10340 > URL: https://issues.apache.org/jira/browse/OAK-10340 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The hidden child order property on the source parent of a move operation is > not updated when the moved node was orderable under the source parent. > The issue does not seem serious, because AbstractTree.getChildNames() is > quite lenient and will add children not present in :childOrder at the end of > the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10340) Child order not updated on source after move
Marcel Reutegger created OAK-10340: -- Summary: Child order not updated on source after move Key: OAK-10340 URL: https://issues.apache.org/jira/browse/OAK-10340 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Marcel Reutegger Assignee: Marcel Reutegger The hidden child order property on the source parent of a move operation is not updated when the moved node was orderable under the source parent. The issue does not seem serious, because AbstractTree.getChildNames() is quite lenient and will add children not present in :childOrder at the end of the returned Iterable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739476#comment-17739476 ] Marcel Reutegger commented on OAK-10334: Read and write are distinct permissions. There are aggregates that include both, but generally it is possible to deny read and allow write of an item. See also test in PR. > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10294) Indexing job: add new Pipelined Strategy for dumping Mongo contents in preparation for reindexing
[ https://issues.apache.org/jira/browse/OAK-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10294: --- Description: (was: [~nuno.santos] & [~nuno.santos], please set a fix version when an issue is resolved. I just did and set it to 1.54.0.) [~thomasm] & [~nuno.santos], please set a fix version when an issue is resolved. I just did and set it to 1.54.0. > Indexing job: add new Pipelined Strategy for dumping Mongo contents in > preparation for reindexing > - > > Key: OAK-10294 > URL: https://issues.apache.org/jira/browse/OAK-10294 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Major > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10294) Indexing job: add new Pipelined Strategy for dumping Mongo contents in preparation for reindexing
[ https://issues.apache.org/jira/browse/OAK-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-10294: --- Fix Version/s: 1.54.0 Description: [~nuno.santos] & [~nuno.santos], please set a fix version when an issue is resolved. I just did and set it to 1.54.0. > Indexing job: add new Pipelined Strategy for dumping Mongo contents in > preparation for reindexing > - > > Key: OAK-10294 > URL: https://issues.apache.org/jira/browse/OAK-10294 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Major > Fix For: 1.54.0 > > > [~nuno.santos] & [~nuno.santos], please set a fix version when an issue is > resolved. I just did and set it to 1.54.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739119#comment-17739119 ] Marcel Reutegger commented on OAK-10334: PR now contains a proposed fix. Adding a mixin type now also requires read permission on jcr:mixinTypes. [~angela], WDYT? > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10334) Node.addMixin() may overwrite existing mixins
[ https://issues.apache.org/jira/browse/OAK-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739102#comment-17739102 ] Marcel Reutegger commented on OAK-10334: Created draft PR with a test reproducing the issue: https://github.com/apache/jackrabbit-oak/pull/1011 > Node.addMixin() may overwrite existing mixins > - > > Key: OAK-10334 > URL: https://issues.apache.org/jira/browse/OAK-10334 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Reporter: Marcel Reutegger >Priority: Major > > A Session lacking permission to read property jcr:mixinTypes, but permission > to write will overwrite existing mixins when calling Node.addMixin(). > The implementation does not check if the session has permission to read > jcr:mixinTypes and assumes there are no existing values when the session does > not have permission. The result is a jcr:mixinTypes property with only a > single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10334) Node.addMixin() may overwrite existing mixins
Marcel Reutegger created OAK-10334: -- Summary: Node.addMixin() may overwrite existing mixins Key: OAK-10334 URL: https://issues.apache.org/jira/browse/OAK-10334 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Reporter: Marcel Reutegger A Session lacking permission to read property jcr:mixinTypes, but permission to write will overwrite existing mixins when calling Node.addMixin(). The implementation does not check if the session has permission to read jcr:mixinTypes and assumes there are no existing values when the session does not have permission. The result is a jcr:mixinTypes property with only a single value passed to addMixin(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10313) Identify revisions created by late-write scenario
[ https://issues.apache.org/jira/browse/OAK-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10313. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR. > Identify revisions created by late-write scenario > - > > Key: OAK-10313 > URL: https://issues.apache.org/jira/browse/OAK-10313 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk, run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > OAK-10254 describes a 'late-write' scenario where a DocumentNodeStore is > writing some changes after its lease timed out. > Introduce a consistency check that identifies those revisions on a > NodeDocument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10315. Resolution: Fixed DocumentStoreCheckCommandTest was successful. Merged PR. > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10330) oak-it-osgi: temporarily introduce Guava dependency again
[
https://issues.apache.org/jira/browse/OAK-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-10330.
Fix Version/s: 1.54.0
Resolution: Fixed
OSGiT tests look good now. Merged PR.
> oak-it-osgi: temporarily introduce Guava dependency again
> -
>
> Key: OAK-10330
> URL: https://issues.apache.org/jira/browse/OAK-10330
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: it
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.54.0
>
>
> OAK-10218 removed Guava as a dependency, but with OAK-10307 original Guava is
> no more leaking through our Oak shaded version and now various tests in
> OsgiIT fail when executed in module oak-it-osgi.
> {noformat}
> [ERROR] Errors:
> [ERROR] OSGiIT.bundleStates » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.listBundles » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSto...
> [ERROR] OSGiIT.listServices » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.testLeaseFailureHandlerIsExported » ClassNotFound
> org.apache.jackrabbit...
> [ERROR] OSGiIT.testNodeStore » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeS...
> [ERROR] OSGiIT.testRepository » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.Node...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10330) oak-it-osgi: temporarily introduce Guava dependency again
[
https://issues.apache.org/jira/browse/OAK-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737539#comment-17737539
]
Marcel Reutegger commented on OAK-10330:
Proposed fix: https://github.com/apache/jackrabbit-oak/pull/1009
> oak-it-osgi: temporarily introduce Guava dependency again
> -
>
> Key: OAK-10330
> URL: https://issues.apache.org/jira/browse/OAK-10330
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: it
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
>
> OAK-10218 removed Guava as a dependency, but with OAK-10307 original Guava is
> no more leaking through our Oak shaded version and now various tests in
> OsgiIT fail when executed in module oak-it-osgi.
> {noformat}
> [ERROR] Errors:
> [ERROR] OSGiIT.bundleStates » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.listBundles » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSto...
> [ERROR] OSGiIT.listServices » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeSt...
> [ERROR] OSGiIT.testLeaseFailureHandlerIsExported » ClassNotFound
> org.apache.jackrabbit...
> [ERROR] OSGiIT.testNodeStore » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.NodeS...
> [ERROR] OSGiIT.testRepository » ClassNotFound
> org.apache.jackrabbit.oak.spi.state.Node...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10330) oak-it-osgi: temporarily introduce Guava dependency again
Marcel Reutegger created OAK-10330:
--
Summary: oak-it-osgi: temporarily introduce Guava dependency again
Key: OAK-10330
URL: https://issues.apache.org/jira/browse/OAK-10330
Project: Jackrabbit Oak
Issue Type: Technical task
Components: it
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
OAK-10218 removed Guava as a dependency, but with OAK-10307 original Guava is
no more leaking through our Oak shaded version and now various tests in OsgiIT
fail when executed in module oak-it-osgi.
{noformat}
[ERROR] Errors:
[ERROR] OSGiIT.bundleStates » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeSt...
[ERROR] OSGiIT.listBundles » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeSto...
[ERROR] OSGiIT.listServices » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeSt...
[ERROR] OSGiIT.testLeaseFailureHandlerIsExported » ClassNotFound
org.apache.jackrabbit...
[ERROR] OSGiIT.testNodeStore » ClassNotFound
org.apache.jackrabbit.oak.spi.state.NodeS...
[ERROR] OSGiIT.testRepository » ClassNotFound
org.apache.jackrabbit.oak.spi.state.Node...
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737536#comment-17737536 ] Marcel Reutegger commented on OAK-10315: Proposed fix: https://github.com/apache/jackrabbit-oak/pull/1008 > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reopened OAK-10315: Need to re-open. This change introduced test failures in oak-run. > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10315. Fix Version/s: 1.54.0 Resolution: Fixed Merged the PR. > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[ https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-5782. --- Resolution: Cannot Reproduce Merged the PR that ignores the test. Resolving as cannot reproduce again. > Test failure: persistentCache.BroadcastTest.broadcastTCP > - > > Key: OAK-5782 > URL: https://issues.apache.org/jira/browse/OAK-5782 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, continuous integration, core >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Marcel Reutegger >Priority: Major > Labels: test-failure, ubuntu > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10321) Remove residual use of original Guava in oak-store-document
[
https://issues.apache.org/jira/browse/OAK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736075#comment-17736075
]
Marcel Reutegger commented on OAK-10321:
OK, then let's keep these for now.
> Remove residual use of original Guava in oak-store-document
> ---
>
> Key: OAK-10321
> URL: https://issues.apache.org/jira/browse/OAK-10321
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Some code still uses original Guava classes.
> {noformat}
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1328,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1389,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[631,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[1777,81]
> package com.google.common.util.concurrent does not exist
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10321) Remove residual use of original Guava in oak-store-document
[
https://issues.apache.org/jira/browse/OAK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17736055#comment-17736055
]
Marcel Reutegger commented on OAK-10321:
I don't think these are needed anymore.
{noformat}
diff --git
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
index 22b6244792..9c4cee90d0 100644
---
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
+++
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
@@ -1325,7 +1325,7 @@ public final class DocumentNodeStore
|| node.equals(missing) ? null : node;
PERFLOG.end(start, 1, "getNode: path={}, rev={}", path, rev);
return result;
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException e) {
+} catch (UncheckedExecutionException e) {
throw DocumentStoreException.convert(e.getCause());
} catch (ExecutionException e) {
throw DocumentStoreException.convert(e.getCause());
@@ -1386,7 +1386,7 @@ public final class DocumentNodeStore
nodeChildrenCache.put(key, children);
}
return children;
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException e) {
+} catch (UncheckedExecutionException e) {
throw DocumentStoreException.convert(e.getCause(),
"Error occurred while fetching children for path "
+ path);
diff --git
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
index 8b21976f30..1f156f4100 100644
---
a/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
+++
b/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java
@@ -628,7 +628,7 @@ public class MongoDocumentStore implements DocumentStore {
} else {
return (T) doc;
}
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException e) {
+} catch (UncheckedExecutionException e) {
t = e.getCause();
} catch (ExecutionException e) {
t = e.getCause();
@@ -1774,7 +1774,7 @@ public class MongoDocumentStore implements DocumentStore {
}
}
return;
-} catch (UncheckedExecutionException |
com.google.common.util.concurrent.UncheckedExecutionException |
ExecutionException e) {
+} catch (UncheckedExecutionException | ExecutionException e) {
t = e.getCause();
} catch (RuntimeException e) {
t = e;
{noformat}
[~reschke], WDYT?
> Remove residual use of original Guava in oak-store-document
> ---
>
> Key: OAK-10321
> URL: https://issues.apache.org/jira/browse/OAK-10321
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Some code still uses original Guava classes.
> {noformat}
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1328,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1389,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[631,81]
> package com.google.common.util.concurrent does not exist
> [ERROR]
> /home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[1777,81]
> package com.google.common.util.concurrent does not exist
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10321) Remove residual use of original Guava in oak-store-document
Marcel Reutegger created OAK-10321:
--
Summary: Remove residual use of original Guava in
oak-store-document
Key: OAK-10321
URL: https://issues.apache.org/jira/browse/OAK-10321
Project: Jackrabbit Oak
Issue Type: Technical task
Components: documentmk
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Some code still uses original Guava classes.
{noformat}
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1328,81]
package com.google.common.util.concurrent does not exist
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java:[1389,81]
package com.google.common.util.concurrent does not exist
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[631,81]
package com.google.common.util.concurrent does not exist
[ERROR]
/home/jenkins/jenkins-agent/workspace/Jackrabbit_oak-trunk-pr_PR-997/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java:[1777,81]
package com.google.common.util.concurrent does not exist
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[ https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735347#comment-17735347 ] Marcel Reutegger commented on OAK-5782: --- PR to ignore the test: https://github.com/apache/jackrabbit-oak/pull/997 > Test failure: persistentCache.BroadcastTest.broadcastTCP > - > > Key: OAK-5782 > URL: https://issues.apache.org/jira/browse/OAK-5782 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, continuous integration, core >Affects Versions: 1.6.0 >Reporter: Hudson >Assignee: Marcel Reutegger >Priority: Major > Labels: test-failure, ubuntu > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-5782) Test failure: persistentCache.BroadcastTest.broadcastTCP
[
https://issues.apache.org/jira/browse/OAK-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reopened OAK-5782:
---
Assignee: Marcel Reutegger (was: Thomas Mueller)
Still fails occasionally.
{noformat}
[ERROR]
broadcastTCP(org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest)
Time elapsed: 10.125 s <<< FAILURE! java.lang.AssertionError: expected null,
but was:
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotNull(Assert.java:756)
at org.junit.Assert.assertNull(Assert.java:738)
at org.junit.Assert.assertNull(Assert.java:748)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTry(BroadcastTest.java:223)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcast(BroadcastTest.java:196)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTCP(BroadcastTest.java:147)
{noformat}
> Test failure: persistentCache.BroadcastTest.broadcastTCP
> -
>
> Key: OAK-5782
> URL: https://issues.apache.org/jira/browse/OAK-5782
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: cache, continuous integration, core
>Affects Versions: 1.6.0
>Reporter: Hudson
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: test-failure, ubuntu
>
> Jenkins CI failure:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
> The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8
> (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1447 has failed.
> First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK
> 1.8 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting
> #1447|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/]
> [console
> log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1447/console]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10315) Counter for DocumentStore check
[ https://issues.apache.org/jira/browse/OAK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735336#comment-17735336 ] Marcel Reutegger commented on OAK-10315: Proposed implementation: https://github.com/apache/jackrabbit-oak/pull/996 > Counter for DocumentStore check > --- > > Key: OAK-10315 > URL: https://issues.apache.org/jira/browse/OAK-10315 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > Introduce a counter option for the documentstore-check command in oak-run. > The option should enable a processor that counts the number of documents and > nodes that exist. The ratio is useful to determine how many documents are > considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10315) Counter for DocumentStore check
Marcel Reutegger created OAK-10315: -- Summary: Counter for DocumentStore check Key: OAK-10315 URL: https://issues.apache.org/jira/browse/OAK-10315 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Marcel Reutegger Assignee: Marcel Reutegger Introduce a counter option for the documentstore-check command in oak-run. The option should enable a processor that counts the number of documents and nodes that exist. The ratio is useful to determine how many documents are considered garbage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10313) Identify revisions created by late-write scenario
[ https://issues.apache.org/jira/browse/OAK-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17734218#comment-17734218 ] Marcel Reutegger commented on OAK-10313: Created new tests in WriteAfterRecoveryTest similar to those in OAK-10254, but using the existing FailingDocumentStore (with some enhancements) to simulate 'late-write' scenarios for various content changes. The consistency check takes a root node state and a NodeDocument and identifies change revisions that are not visible when traversing to the node state represented by the given NodeDocument even though they should be given the head revision on the root node state. Proposed changed in https://github.com/apache/jackrabbit-oak/pull/995 > Identify revisions created by late-write scenario > - > > Key: OAK-10313 > URL: https://issues.apache.org/jira/browse/OAK-10313 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk, run >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > OAK-10254 describes a 'late-write' scenario where a DocumentNodeStore is > writing some changes after its lease timed out. > Introduce a consistency check that identifies those revisions on a > NodeDocument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10313) Identify revisions created by late-write scenario
Marcel Reutegger created OAK-10313: -- Summary: Identify revisions created by late-write scenario Key: OAK-10313 URL: https://issues.apache.org/jira/browse/OAK-10313 Project: Jackrabbit Oak Issue Type: Task Components: documentmk, run Reporter: Marcel Reutegger Assignee: Marcel Reutegger OAK-10254 describes a 'late-write' scenario where a DocumentNodeStore is writing some changes after its lease timed out. Introduce a consistency check that identifies those revisions on a NodeDocument. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10308) Tests using MongoUtils may skip even if Docker is available
[ https://issues.apache.org/jira/browse/OAK-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10308. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR. > Tests using MongoUtils may skip even if Docker is available > --- > > Key: OAK-10308 > URL: https://issues.apache.org/jira/browse/OAK-10308 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > MongoUtil first tries to connect to an already running MongoDB on the default > port and then tries to start MongoDB in docker. The latter may fail even when > docker is available and MongoDB is started successfully. > The host for the constructed connection URI is hardcoded to 'localhost', > which may not work when docker exposed MongoDB on 127.0.0.1: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10308) Tests using MongoUtils may skip even if Docker is available
[ https://issues.apache.org/jira/browse/OAK-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733136#comment-17733136 ] Marcel Reutegger commented on OAK-10308: Proposed changes: https://github.com/apache/jackrabbit-oak/pull/990 > Tests using MongoUtils may skip even if Docker is available > --- > > Key: OAK-10308 > URL: https://issues.apache.org/jira/browse/OAK-10308 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > MongoUtil first tries to connect to an already running MongoDB on the default > port and then tries to start MongoDB in docker. The latter may fail even when > docker is available and MongoDB is started successfully. > The host for the constructed connection URI is hardcoded to 'localhost', > which may not work when docker exposed MongoDB on 127.0.0.1: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10308) Tests using MongoUtils may skip even if Docker is available
Marcel Reutegger created OAK-10308: -- Summary: Tests using MongoUtils may skip even if Docker is available Key: OAK-10308 URL: https://issues.apache.org/jira/browse/OAK-10308 Project: Jackrabbit Oak Issue Type: Bug Components: documentmk, mongomk Reporter: Marcel Reutegger Assignee: Marcel Reutegger MongoUtil first tries to connect to an already running MongoDB on the default port and then tries to start MongoDB in docker. The latter may fail even when docker is available and MongoDB is started successfully. The host for the constructed connection URI is hardcoded to 'localhost', which may not work when docker exposed MongoDB on 127.0.0.1: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10306) Incorrect dependency scope for commons-math3
[ https://issues.apache.org/jira/browse/OAK-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10306. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR. > Incorrect dependency scope for commons-math3 > > > Key: OAK-10306 > URL: https://issues.apache.org/jira/browse/OAK-10306 > Project: Jackrabbit Oak > Issue Type: Bug > Components: commons >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > The dependency commons-math3 is only used for tests in oak-commons, but is > currently set to compile and optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10288) mvn test for oak-commons fails in top level directory, but not in project directory
[
https://issues.apache.org/jira/browse/OAK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733049#comment-17733049
]
Marcel Reutegger commented on OAK-10288:
Created OAK-10307 for the transitive dependency issue with oak-shaded-guava.
> mvn test for oak-commons fails in top level directory, but not in project
> directory
> ---
>
> Key: OAK-10288
> URL: https://issues.apache.org/jira/browse/OAK-10288
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: commons
>Reporter: Manfred Baedke
>Priority: Minor
>
> While
> {code:java}
> mvn clean install{code}
> is running fine,
> {code:java}
> mvn test{code}
> is failing due to
> {code:java}
> java.lang.ClassNotFoundException:
> org.apache.jackrabbit.guava.common.collect.Sets{code}
> , but only when run in the top level directory. It will succeed when run in
> the oak-commons project directory.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10307) oak-shaded-guava leaks original guava as transitive dependency
Marcel Reutegger created OAK-10307:
--
Summary: oak-shaded-guava leaks original guava as transitive
dependency
Key: OAK-10307
URL: https://issues.apache.org/jira/browse/OAK-10307
Project: Jackrabbit Oak
Issue Type: Technical task
Components: shaded-guava
Reporter: Marcel Reutegger
oak-shaded-guava currently declares a compile dependency on original guava.
This means modules using oak-shaded-guava will transitively get original guava
and mistakingly use classes from there.
{noformat}
$ mvn dependency:tree -pl :oak-shaded-guava
[INFO] Scanning for projects...
[INFO]
[INFO] ---< org.apache.jackrabbit:oak-shaded-guava >---
[INFO] Building Jackrabbit Guava Wrapper 1.53-SNAPSHOT
[INFO] from pom.xml
[INFO] ---[ bundle ]---
[INFO]
[INFO] --- dependency:3.4.0:tree (default-cli) @ oak-shaded-guava ---
[INFO] org.apache.jackrabbit:oak-shaded-guava:bundle:1.53-SNAPSHOT
[INFO] +- com.google.guava:guava:jar:32.0.1-jre:compile
[INFO] | +- com.google.guava:failureaccess:jar:1.0.1:compile
[INFO] | +-
com.google.guava:listenablefuture:jar:.0-empty-to-avoid-conflict-with-guava:compile
[INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.2:compile
[INFO] | +- org.checkerframework:checker-qual:jar:3.33.0:compile
[INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.18.0:compile
[INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile
[INFO] +- org.osgi:org.osgi.annotation:jar:6.0.0:provided
[INFO] \- org.jetbrains:annotations:jar:18.0.0:provided
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10247) oak-commons: remove Guava from public API
[ https://issues.apache.org/jira/browse/OAK-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733036#comment-17733036 ] Marcel Reutegger commented on OAK-10247: This looks incomplete to me. There are still usages of Guava 15 in oak-commons. E.g. https://github.com/apache/jackrabbit-oak/blob/trunk/oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/FileIOUtils.java#L73 The problem is oak-shaded-guava which silently introduced Guava 15 again as transitive dependency. See also [comment|https://issues.apache.org/jira/browse/OAK-10288?focusedCommentId=17733026=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17733026] in OAK-10288. > oak-commons: remove Guava from public API > - > > Key: OAK-10247 > URL: https://issues.apache.org/jira/browse/OAK-10247 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: commons >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.54.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10306) Incorrect dependency scope for commons-math3
[ https://issues.apache.org/jira/browse/OAK-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733035#comment-17733035 ] Marcel Reutegger commented on OAK-10306: Proposed changes: https://github.com/apache/jackrabbit-oak/pull/985 > Incorrect dependency scope for commons-math3 > > > Key: OAK-10306 > URL: https://issues.apache.org/jira/browse/OAK-10306 > Project: Jackrabbit Oak > Issue Type: Bug > Components: commons >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > The dependency commons-math3 is only used for tests in oak-commons, but is > currently set to compile and optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10288) mvn test for oak-commons fails in top level directory, but not in project directory
[
https://issues.apache.org/jira/browse/OAK-10288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733026#comment-17733026
]
Marcel Reutegger commented on OAK-10288:
It doesn't really explain the different behaviour, but oak-commons still has an
undeclared dependency to Guava 15.
{noformat}
mvn dependency:analyze -pl :oak-commons
{noformat}
says:
{noformat}
[INFO] --- dependency:3.4.0:analyze (default-cli) @ oak-commons ---
[WARNING] Used undeclared dependencies found:
[WARNING]ch.qos.logback:logback-core:jar:1.2.10:test
[WARNING]org.hamcrest:hamcrest-core:jar:1.3:test
[WARNING]com.google.guava:guava:jar:15.0:compile
{noformat}
Hmm, it is a transitive dependency through oak-shaded-guava.
{noformat}
$ mvn dependency:tree -pl :oak-commons
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.apache.jackrabbit:oak-commons >--
[INFO] Building Oak Commons 1.53-SNAPSHOT
[INFO] from pom.xml
[INFO] ---[ bundle ]---
[INFO]
[INFO] --- dependency:3.4.0:tree (default-cli) @ oak-commons ---
[INFO] org.apache.jackrabbit:oak-commons:bundle:1.53-SNAPSHOT
[INFO] +- org.osgi:org.osgi.annotation:jar:6.0.0:provided
[INFO] +- org.slf4j:slf4j-api:jar:1.7.36:compile
[INFO] +- org.jetbrains:annotations:jar:18.0.0:provided
[INFO] +- commons-io:commons-io:jar:2.11.0:compile
[INFO] +- org.apache.jackrabbit:jackrabbit-jcr-commons:jar:2.20.10:compile
[INFO] +- org.apache.jackrabbit:oak-shaded-guava:jar:1.53-SNAPSHOT:compile
[INFO] | \- com.google.guava:guava:jar:15.0:compile
[INFO] +- junit:junit:jar:4.13.1:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- ch.qos.logback:logback-classic:jar:1.2.10:test
[INFO] | \- ch.qos.logback:logback-core:jar:1.2.10:test
[INFO] +- org.apache.commons:commons-math3:jar:3.6.1:test
[INFO] +- org.apache.commons:commons-lang3:jar:3.12.0:test
[INFO] +- org.mockito:mockito-core:jar:4.11.0:test
[INFO] | +- net.bytebuddy:byte-buddy:jar:1.12.19:test
[INFO] | +- net.bytebuddy:byte-buddy-agent:jar:1.12.19:test
[INFO] | \- org.objenesis:objenesis:jar:3.3:test
[INFO] \- org.lz4:lz4-java:jar:1.8.0:test
{noformat}
Wouldn't it be better if oak-shaded-guava doesn't leak native guava 15?
> mvn test for oak-commons fails in top level directory, but not in project
> directory
> ---
>
> Key: OAK-10288
> URL: https://issues.apache.org/jira/browse/OAK-10288
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: commons
>Reporter: Manfred Baedke
>Priority: Minor
>
> While
> {code:java}
> mvn clean install{code}
> is running fine,
> {code:java}
> mvn test{code}
> is failing due to
> {code:java}
> java.lang.ClassNotFoundException:
> org.apache.jackrabbit.guava.common.collect.Sets{code}
> , but only when run in the top level directory. It will succeed when run in
> the oak-commons project directory.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10306) Incorrect dependency scope for commons-math3
Marcel Reutegger created OAK-10306: -- Summary: Incorrect dependency scope for commons-math3 Key: OAK-10306 URL: https://issues.apache.org/jira/browse/OAK-10306 Project: Jackrabbit Oak Issue Type: Bug Components: commons Reporter: Marcel Reutegger Assignee: Marcel Reutegger The dependency commons-math3 is only used for tests in oak-commons, but is currently set to compile and optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10295) KeyDataType does not define or inherit an implementation of the resolved method 'abstract void write()
[
https://issues.apache.org/jira/browse/OAK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-10295:
---
Component/s: documentmk
(was: jackrabbit-api)
> KeyDataType does not define or inherit an implementation of the resolved
> method 'abstract void write()
> --
>
> Key: OAK-10295
> URL: https://issues.apache.org/jira/browse/OAK-10295
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.50.0
>Reporter: Wallace Howery
>Priority: Critical
>
> I'm getting the warning below in a JCR Oak project, using postgres for
> storage, and using oak-lucene and oak-store-composite dependencies (to get
> JCR functionality), using version 1.50.0 of those dependencies.
> Also, I'm using JDK 17 and spring-boot 2.5.12.
>
> It looks like
> org.apache.jackrabbit.oak.plugins.document.persistentCache.KeyDataType needs
> to be updated to implement method 'abstract void
> write(org.h2.mvstore.WriteBuffer, java.lang.Object[], int, boolean)' of
> interface org.h2.mvstore.type.DataType.
>
> Could this be looked into be the jackrabbit team?
>
> {"@timestamp":"2023-05-26T11:26:41.994-04:00","@version":"1","message":"Error
> in the background thread of the persistent cache:
> java.lang.IllegalStateException: java.lang.AbstractMethodError: Receiver
> class org.apache.jackrabbit.oak.plugins.document.persistentCache.KeyDataType
> does not define or inherit an implementation of the resolved method 'abstract
> void write(org.h2.mvstore.WriteBuffer, java.lang.Object[], int, boolean)' of
> interface org.h2.mvstore.type.DataType.
> [1.4.200/3]","logger_name":"org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory","thread_name":"MVStore
> background writer
> nio:/data/ace/app/summons/oak/repository/cache/cache-0.data","level":"WARN","level_value":3}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10295) KeyDataType does not define or inherit an implementation of the resolved method 'abstract void write()
[
https://issues.apache.org/jira/browse/OAK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-10295.
Resolution: Not A Problem
Looks like this is not an Oak problem. H2 dependency in Oak was upgraded to a
2.x version with OAK-9668 a while ago.
> KeyDataType does not define or inherit an implementation of the resolved
> method 'abstract void write()
> --
>
> Key: OAK-10295
> URL: https://issues.apache.org/jira/browse/OAK-10295
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jackrabbit-api
>Affects Versions: 1.50.0
>Reporter: Wallace Howery
>Priority: Critical
>
> I'm getting the warning below in a JCR Oak project, using postgres for
> storage, and using oak-lucene and oak-store-composite dependencies (to get
> JCR functionality), using version 1.50.0 of those dependencies.
> Also, I'm using JDK 17 and spring-boot 2.5.12.
>
> It looks like
> org.apache.jackrabbit.oak.plugins.document.persistentCache.KeyDataType needs
> to be updated to implement method 'abstract void
> write(org.h2.mvstore.WriteBuffer, java.lang.Object[], int, boolean)' of
> interface org.h2.mvstore.type.DataType.
>
> Could this be looked into be the jackrabbit team?
>
> {"@timestamp":"2023-05-26T11:26:41.994-04:00","@version":"1","message":"Error
> in the background thread of the persistent cache:
> java.lang.IllegalStateException: java.lang.AbstractMethodError: Receiver
> class org.apache.jackrabbit.oak.plugins.document.persistentCache.KeyDataType
> does not define or inherit an implementation of the resolved method 'abstract
> void write(org.h2.mvstore.WriteBuffer, java.lang.Object[], int, boolean)' of
> interface org.h2.mvstore.type.DataType.
> [1.4.200/3]","logger_name":"org.apache.jackrabbit.oak.plugins.document.persistentCache.MapFactory","thread_name":"MVStore
> background writer
> nio:/data/ace/app/summons/oak/repository/cache/cache-0.data","level":"WARN","level_value":3}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10093) Oak Blob Store support for SSE-C for AWS
[ https://issues.apache.org/jira/browse/OAK-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732971#comment-17732971 ] Marcel Reutegger edited comment on OAK-10093 at 6/15/23 10:02 AM: -- AFAIU [direct binary access|https://jackrabbit.apache.org/oak/docs/features/direct-binary-access.html] feature won't work with customer provided keys. Pre-signed URIs can be created, but when you use such a signed URI you need to know the customer provided key. https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html#ssec-and-presignedurl The primary use for direct binary access is to return a pre-signed URI to the browser and let it download a binary directly from blob storage. This won't work with a customer provided key, because the browser doesn't know and must not have the key. I think this should be mentioned somewhere in the Oak documentation. Probably on https://jackrabbit.apache.org/oak/docs/features/direct-binary-access.html Maybe Oak should even refuse to hand out a pre-signed URI in this case. A client won't be able to do something useful with it anyway. was (Author: mreutegg): AFAIU [direct binary access|https://jackrabbit.apache.org/oak/docs/features/direct-binary-access.html] feature won't work with customer provided keys. Pre-signed URIs can be created, but when you use such a signed URI you need to know the customer provided key. https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html#ssec-and-presignedurl The primary use for direct binary access is to return a pre-signed URI to the browser and let it download a binary directly from blob storage. This won't work with a customer provided key, because the browser doesn't know and must not have the key. I think this should be mentioned somewhere in the Oak documentation. > Oak Blob Store support for SSE-C for AWS > > > Key: OAK-10093 > URL: https://issues.apache.org/jira/browse/OAK-10093 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Rishabh Kumar >Assignee: Rishabh Daim >Priority: Major > > We need to provide the support for Customer Managed keys for Oak Blob Store > for AWS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10093) Oak Blob Store support for SSE-C for AWS
[ https://issues.apache.org/jira/browse/OAK-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732971#comment-17732971 ] Marcel Reutegger commented on OAK-10093: AFAIU [direct binary access|https://jackrabbit.apache.org/oak/docs/features/direct-binary-access.html] feature won't work with customer provided keys. Pre-signed URIs can be created, but when you use such a signed URI you need to know the customer provided key. https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html#ssec-and-presignedurl The primary use for direct binary access is to return a pre-signed URI to the browser and let it download a binary directly from blob storage. This won't work with a customer provided key, because the browser doesn't know and must not have the key. I think this should be mentioned somewhere in the Oak documentation. > Oak Blob Store support for SSE-C for AWS > > > Key: OAK-10093 > URL: https://issues.apache.org/jira/browse/OAK-10093 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Rishabh Kumar >Assignee: Rishabh Daim >Priority: Major > > We need to provide the support for Customer Managed keys for Oak Blob Store > for AWS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10304) Oak allows registration of invalid namespace names
[
https://issues.apache.org/jira/browse/OAK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732887#comment-17732887
]
Marcel Reutegger commented on OAK-10304:
bq. Fixing this may be hard due to legacy content.
Agreed.
+1 on documenting the current behaviour and log a message. Not sure about the
log level though. WARN or ERROR.
> Oak allows registration of invalid namespace names
> --
>
> Key: OAK-10304
> URL: https://issues.apache.org/jira/browse/OAK-10304
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> Example:
> {noformat}
> diff --git
> a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> index f113e4e0d2..7178a36f7f 100644
> --- a/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> +++ b/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java
> @@ -1996,6 +1996,24 @@ public class RepositoryTest extends
> AbstractRepositoryTest {
> assertFalse(asList(nsReg.getURIs()).contains("file:///foo"));
> }
> +@Test
> +public void testNamespaceNames() throws RepositoryException {
> +NamespaceRegistry nsReg =
> +getAdminSession().getWorkspace().getNamespaceRegistry();
> +
> +// valid
> +nsReg.registerNamespace("foo", "https://example.com;);
> +nsReg.unregisterNamespace("foo");
> +
> +// invalid
> +try {
> +nsReg.registerNamespace("foo", "example.com");
> +fail("should not register invalid namespace name");
> +} finally {
> +nsReg.unregisterNamespace("foo");
> +}
> +}
> {noformat}
> Note that name of nodes using invalid namespaces do have a valid "expanded
> form" variant
> (https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/3_Repository_Model.html#3.2.5.1%20Expanded%20Form).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9660) NullPointerException When Moving Transient node
[ https://issues.apache.org/jira/browse/OAK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-9660: -- Labels: candidate_oak_1_22 (was: ) > NullPointerException When Moving Transient node > --- > > Key: OAK-9660 > URL: https://issues.apache.org/jira/browse/OAK-9660 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.8, 1.40.0 >Reporter: Bryan Stopp >Assignee: Marcel Reutegger >Priority: Major > Labels: candidate_oak_1_22 > Fix For: 1.54.0 > > > When a node is moved in a uncommitted Session1 (S), that was previously moved > in a closed/committed Session0 (S'), any transient children nodes that are > moved throw NPEs in the node memory manager tracking the uncommitted state. > > Steps to reproduce: > # Start Sling docker container > ## ` docker run -p 8080:8080 apache/sling` > # Install [demo project|https://github.com/bstopp/oak-move-bug] > # Disable administrative login security, or create a rule for the servlet. > # Navigate to the [Demo servlet|http://localhost:8080/bin/bug/test] > > The servlet will catch the NPE and display it. The error occurs > [here|https://github.com/apache/jackrabbit-oak/blob/74a1a686635be76b74abd57ebc0ef1dd4bb44889/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/memory/MemoryNodeBuilder.java#L449]. > `base` is not null, but `head` is. > It seems that the `base` look up finds the segment metadata from Session0 > (S') that has been dispatched (before the current session was created), and > not recognizing that the parent is now a transient node in Session1 (S). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9660) NullPointerException When Moving Transient node
[ https://issues.apache.org/jira/browse/OAK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-9660. --- Fix Version/s: 1.54.0 Resolution: Fixed Merged PR https://github.com/apache/jackrabbit-oak/pull/975 Bryan, thank you for reporting this issue and the excellent instructions how to reproduce it. > NullPointerException When Moving Transient node > --- > > Key: OAK-9660 > URL: https://issues.apache.org/jira/browse/OAK-9660 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.8, 1.40.0 >Reporter: Bryan Stopp >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.54.0 > > > When a node is moved in a uncommitted Session1 (S), that was previously moved > in a closed/committed Session0 (S'), any transient children nodes that are > moved throw NPEs in the node memory manager tracking the uncommitted state. > > Steps to reproduce: > # Start Sling docker container > ## ` docker run -p 8080:8080 apache/sling` > # Install [demo project|https://github.com/bstopp/oak-move-bug] > # Disable administrative login security, or create a rule for the servlet. > # Navigate to the [Demo servlet|http://localhost:8080/bin/bug/test] > > The servlet will catch the NPE and display it. The error occurs > [here|https://github.com/apache/jackrabbit-oak/blob/74a1a686635be76b74abd57ebc0ef1dd4bb44889/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/memory/MemoryNodeBuilder.java#L449]. > `base` is not null, but `head` is. > It seems that the `base` look up finds the segment metadata from Session0 > (S') that has been dispatched (before the current session was created), and > not recognizing that the parent is now a transient node in Session1 (S). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10147) Many move operations may consume a lot of memory
[ https://issues.apache.org/jira/browse/OAK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10147. Fix Version/s: 1.54.0 Resolution: Fixed Merged the PR. > Many move operations may consume a lot of memory > > > Key: OAK-10147 > URL: https://issues.apache.org/jira/browse/OAK-10147 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Marcel Reutegger >Priority: Major > Fix For: 1.54.0 > > > We have encountered an issue where a component did a huge number of move > operations in transient space, and oak-core's "MutableRoot" class consumed > ~800 MB for ca 3000 move operations. This seems to be a lot. > We should: > 1. Write a test / benchmark that reproduces the issue > 2. Check whether it's specific to a certain store implemention > 3. See whether the memory footprint can be reduced -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10293) AzureTarRevisionsTest fails occasionally
Marcel Reutegger created OAK-10293:
--
Summary: AzureTarRevisionsTest fails occasionally
Key: OAK-10293
URL: https://issues.apache.org/jira/browse/OAK-10293
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-azure
Reporter: Marcel Reutegger
{noformat}
[ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.395 s
<<< FAILURE! - in
org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest
[ERROR]
setHeadFromFunction(org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest)
Time elapsed: 0.043 s <<< ERROR!
org.apache.jackrabbit.oak.segment.file.InvalidFileStoreVersionException: Using
oak-segment-tar, but oak-segment should be used
at
org.apache.jackrabbit.oak.segment.file.ManifestChecker.openManifest(ManifestChecker.java:65)
at
org.apache.jackrabbit.oak.segment.file.ManifestChecker.checkAndUpdateManifest(ManifestChecker.java:51)
at
org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:153)
at
org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:445)
at
org.apache.jackrabbit.oak.segment.file.TarRevisionsTest.setup(TarRevisionsTest.java:74)
at
org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest.setup(AzureTarRevisionsTest.java:41)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10280) Occasional failure to start docker container
[
https://issues.apache.org/jira/browse/OAK-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-10280.
Fix Version/s: 1.54.0
Resolution: Fixed
Merged the PR. Thanks for the review, [~jelmini].
> Occasional failure to start docker container
>
>
> Key: OAK-10280
> URL: https://issues.apache.org/jira/browse/OAK-10280
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, segment-azure
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.54.0
>
>
> Tests in various modules fail occasionally because there is a problem
> starting a docker container. The following is from a recent CI build.
> {noformat}
> [ERROR] org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentAzureTest
> Time elapsed: 30.98 s <<< ERROR!
> java.lang.RuntimeException: Unable to start docker container:
> DockerConfig{name=oak-test-azurite-2881c40a}
> at
> com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:76)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.IllegalStateException: Timeout waiting for socket
> connection to 0.0.0.0:32769
> at com.arakelian.docker.junit.Container.waitForPort(Container.java:404)
> at com.arakelian.docker.junit.Container.waitForPort(Container.java:362)
> at com.arakelian.docker.junit.Container.waitForPort(Container.java:350)
> at
> org.apache.jackrabbit.oak.segment.azure.AzuriteDockerRule.lambda$new$0(AzuriteDockerRule.java:55)
> at com.arakelian.docker.junit.Container.start(Container.java:260)
> at
> com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:72)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-9660) NullPointerException When Moving Transient node
[ https://issues.apache.org/jira/browse/OAK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730881#comment-17730881 ] Marcel Reutegger commented on OAK-9660: --- Proposed fix in https://github.com/apache/jackrabbit-oak/pull/975 > NullPointerException When Moving Transient node > --- > > Key: OAK-9660 > URL: https://issues.apache.org/jira/browse/OAK-9660 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.8, 1.40.0 >Reporter: Bryan Stopp >Assignee: Marcel Reutegger >Priority: Major > > When a node is moved in a uncommitted Session1 (S), that was previously moved > in a closed/committed Session0 (S'), any transient children nodes that are > moved throw NPEs in the node memory manager tracking the uncommitted state. > > Steps to reproduce: > # Start Sling docker container > ## ` docker run -p 8080:8080 apache/sling` > # Install [demo project|https://github.com/bstopp/oak-move-bug] > # Disable administrative login security, or create a rule for the servlet. > # Navigate to the [Demo servlet|http://localhost:8080/bin/bug/test] > > The servlet will catch the NPE and display it. The error occurs > [here|https://github.com/apache/jackrabbit-oak/blob/74a1a686635be76b74abd57ebc0ef1dd4bb44889/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/memory/MemoryNodeBuilder.java#L449]. > `base` is not null, but `head` is. > It seems that the `base` look up finds the segment metadata from Session0 > (S') that has been dispatched (before the current session was created), and > not recognizing that the parent is now a transient node in Session1 (S). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9660) NullPointerException When Moving Transient node
[ https://issues.apache.org/jira/browse/OAK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730879#comment-17730879 ] Marcel Reutegger commented on OAK-9660: --- Rebased and merged the PR with the test. > NullPointerException When Moving Transient node > --- > > Key: OAK-9660 > URL: https://issues.apache.org/jira/browse/OAK-9660 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.8, 1.40.0 >Reporter: Bryan Stopp >Assignee: Marcel Reutegger >Priority: Major > > When a node is moved in a uncommitted Session1 (S), that was previously moved > in a closed/committed Session0 (S'), any transient children nodes that are > moved throw NPEs in the node memory manager tracking the uncommitted state. > > Steps to reproduce: > # Start Sling docker container > ## ` docker run -p 8080:8080 apache/sling` > # Install [demo project|https://github.com/bstopp/oak-move-bug] > # Disable administrative login security, or create a rule for the servlet. > # Navigate to the [Demo servlet|http://localhost:8080/bin/bug/test] > > The servlet will catch the NPE and display it. The error occurs > [here|https://github.com/apache/jackrabbit-oak/blob/74a1a686635be76b74abd57ebc0ef1dd4bb44889/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/memory/MemoryNodeBuilder.java#L449]. > `base` is not null, but `head` is. > It seems that the `base` look up finds the segment metadata from Session0 > (S') that has been dispatched (before the current session was created), and > not recognizing that the parent is now a transient node in Session1 (S). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-9660) NullPointerException When Moving Transient node
[ https://issues.apache.org/jira/browse/OAK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-9660: - Assignee: Marcel Reutegger > NullPointerException When Moving Transient node > --- > > Key: OAK-9660 > URL: https://issues.apache.org/jira/browse/OAK-9660 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.8.8, 1.40.0 >Reporter: Bryan Stopp >Assignee: Marcel Reutegger >Priority: Major > > When a node is moved in a uncommitted Session1 (S), that was previously moved > in a closed/committed Session0 (S'), any transient children nodes that are > moved throw NPEs in the node memory manager tracking the uncommitted state. > > Steps to reproduce: > # Start Sling docker container > ## ` docker run -p 8080:8080 apache/sling` > # Install [demo project|https://github.com/bstopp/oak-move-bug] > # Disable administrative login security, or create a rule for the servlet. > # Navigate to the [Demo servlet|http://localhost:8080/bin/bug/test] > > The servlet will catch the NPE and display it. The error occurs > [here|https://github.com/apache/jackrabbit-oak/blob/74a1a686635be76b74abd57ebc0ef1dd4bb44889/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/memory/MemoryNodeBuilder.java#L449]. > `base` is not null, but `head` is. > It seems that the `base` look up finds the segment metadata from Session0 > (S') that has been dispatched (before the current session was created), and > not recognizing that the parent is now a transient node in Session1 (S). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10280) Occasional failure to start docker container
[
https://issues.apache.org/jira/browse/OAK-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730848#comment-17730848
]
Marcel Reutegger commented on OAK-10280:
Proposed changes in https://github.com/apache/jackrabbit-oak/pull/969
The PR consolidates three AzuriteDockerRule classes and updates tests to use a
single AzuriteDockerRule in oak-blob-cloud-azure.
> Occasional failure to start docker container
>
>
> Key: OAK-10280
> URL: https://issues.apache.org/jira/browse/OAK-10280
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk, segment-azure
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
>
> Tests in various modules fail occasionally because there is a problem
> starting a docker container. The following is from a recent CI build.
> {noformat}
> [ERROR] org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentAzureTest
> Time elapsed: 30.98 s <<< ERROR!
> java.lang.RuntimeException: Unable to start docker container:
> DockerConfig{name=oak-test-azurite-2881c40a}
> at
> com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:76)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
> Caused by: java.lang.IllegalStateException: Timeout waiting for socket
> connection to 0.0.0.0:32769
> at com.arakelian.docker.junit.Container.waitForPort(Container.java:404)
> at com.arakelian.docker.junit.Container.waitForPort(Container.java:362)
> at com.arakelian.docker.junit.Container.waitForPort(Container.java:350)
> at
> org.apache.jackrabbit.oak.segment.azure.AzuriteDockerRule.lambda$new$0(AzuriteDockerRule.java:55)
> at com.arakelian.docker.junit.Container.start(Container.java:260)
> at
> com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:72)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10280) Occasional failure to start docker container
Marcel Reutegger created OAK-10280:
--
Summary: Occasional failure to start docker container
Key: OAK-10280
URL: https://issues.apache.org/jira/browse/OAK-10280
Project: Jackrabbit Oak
Issue Type: Bug
Components: documentmk, segment-azure
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Tests in various modules fail occasionally because there is a problem starting
a docker container. The following is from a recent CI build.
{noformat}
[ERROR] org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentAzureTest
Time elapsed: 30.98 s <<< ERROR!
java.lang.RuntimeException: Unable to start docker container:
DockerConfig{name=oak-test-azurite-2881c40a}
at
com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:76)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Caused by: java.lang.IllegalStateException: Timeout waiting for socket
connection to 0.0.0.0:32769
at com.arakelian.docker.junit.Container.waitForPort(Container.java:404)
at com.arakelian.docker.junit.Container.waitForPort(Container.java:362)
at com.arakelian.docker.junit.Container.waitForPort(Container.java:350)
at
org.apache.jackrabbit.oak.segment.azure.AzuriteDockerRule.lambda$new$0(AzuriteDockerRule.java:55)
at com.arakelian.docker.junit.Container.start(Container.java:260)
at
com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:72)
... 11 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10254) Test cases to reproduce late write inconsistencies
[ https://issues.apache.org/jira/browse/OAK-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729236#comment-17729236 ] Marcel Reutegger commented on OAK-10254: [~stefanegli], the PR is merged, but this issue is still in progress. Can this be resolved? > Test cases to reproduce late write inconsistencies > -- > > Key: OAK-10254 > URL: https://issues.apache.org/jira/browse/OAK-10254 > Project: Jackrabbit Oak > Issue Type: Task > Components: documentmk >Reporter: Stefan Egli >Assignee: Stefan Egli >Priority: Major > > Test class that reproduces "late-write inconsistencies". These are a type of > inconsistencies that can happen if a write manages to be sent to > DocumentStore after the lease expired and other instances already did a > lastRevRecovery. This is a scenario that can occur if the JVM experiences a > stop-the-world JVM-GC for longer than the lease duration (eg 2min) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10147) Many move operations may consume a lot of memory
[
https://issues.apache.org/jira/browse/OAK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728395#comment-17728395
]
Marcel Reutegger commented on OAK-10147:
During a discussions with [~stefanegli], [~daim], [~corderob] and [~ankitaagar]
the suggestions was made to try to get rid of {{Move.destParent}} to reduce
memory usage. With only the source and destination path left in a Move, memory
usage will be drastically lower even when a MutableTree still references many
pending Move operations.
The PR https://github.com/apache/jackrabbit-oak/pull/962 is an implementation
of this idea. The current implementation is retained and can be enabled again
either with a system property {{oak.classicMove}} or feature toggle
{{OAK-10147}}.
I'd still like to spend a bit more time and add tests. I already discovered an
issue in the current implementation (ClassicMoveTest#moveMoved()), which works
fine on the new implementation. Either disable feature flag in ClassicMoveTest
to run on the new implementation or run RootTest in oak-it, which has the same
test.
> Many move operations may consume a lot of memory
>
>
> Key: OAK-10147
> URL: https://issues.apache.org/jira/browse/OAK-10147
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Major
>
> We have encountered an issue where a component did a huge number of move
> operations in transient space, and oak-core's "MutableRoot" class consumed
> ~800 MB for ca 3000 move operations. This seems to be a lot.
> We should:
> 1. Write a test / benchmark that reproduces the issue
> 2. Check whether it's specific to a certain store implemention
> 3. See whether the memory footprint can be reduced
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10266) ClientIpFilterTest fails for localhost
[ https://issues.apache.org/jira/browse/OAK-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-10266: -- Assignee: (was: Marcel Reutegger) > ClientIpFilterTest fails for localhost > -- > > Key: OAK-10266 > URL: https://issues.apache.org/jira/browse/OAK-10266 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Marcel Reutegger >Priority: Minor > > ClientIpFilterTest fails on my machine for filters=localhost. > The JVM returns an IP v6 address, which does not match the expected 127.0.0.1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10266) ClientIpFilterTest fails for localhost
[ https://issues.apache.org/jira/browse/OAK-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned OAK-10266: -- Assignee: Marcel Reutegger > ClientIpFilterTest fails for localhost > -- > > Key: OAK-10266 > URL: https://issues.apache.org/jira/browse/OAK-10266 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > > ClientIpFilterTest fails on my machine for filters=localhost. > The JVM returns an IP v6 address, which does not match the expected 127.0.0.1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10266) ClientIpFilterTest fails for localhost
Marcel Reutegger created OAK-10266: -- Summary: ClientIpFilterTest fails for localhost Key: OAK-10266 URL: https://issues.apache.org/jira/browse/OAK-10266 Project: Jackrabbit Oak Issue Type: Bug Components: segment-tar Reporter: Marcel Reutegger ClientIpFilterTest fails on my machine for filters=localhost. The JVM returns an IP v6 address, which does not match the expected 127.0.0.1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10259) oak-core tests running out of memory
[ https://issues.apache.org/jira/browse/OAK-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-10259. Fix Version/s: 1.54.0 Resolution: Fixed Merged PR. > oak-core tests running out of memory > > > Key: OAK-10259 > URL: https://issues.apache.org/jira/browse/OAK-10259 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.54.0 > > > Recently tests for oak-core were running out of memory on Jenkins. Analyzing > a heap dump showed majority of heap (300 MB) retained by Mockito. It looks > like this is related to https://github.com/mockito/mockito/pull/1619 and with > OAK-10173 we enabled mock-maker-inline. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10213) Add new api in DocumentStore to handle bulk findAndUpdate operations
[ https://issues.apache.org/jira/browse/OAK-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726207#comment-17726207 ] Marcel Reutegger commented on OAK-10213: bq. The new method would be used to implement all the planned deletions in Detailed RGC i.e. Properties, OldRevisions, or any other property that we might plan to remove in the future. As an alternative, the cleanup work could also be delegated to VersionGCSupport and then have an optimized implementation in MongoVersionGCSupport without adding a method to the DocumentStore interface. Credits to Julian Reschke, who mentioned this in a conversation I had with him. > Add new api in DocumentStore to handle bulk findAndUpdate operations > > > Key: OAK-10213 > URL: https://issues.apache.org/jira/browse/OAK-10213 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Rishabh Daim >Assignee: Rishabh Daim >Priority: Major > > Currently, we only provide support to update 1 document using > [findAndUpdate|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentStore.java#L348] > with conditions. > > For my ticket OAK-10199, I need to update multiple documents. However, none > of the existing APIs fit my use case. > Using > [findAndUpdate|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentStore.java#L348] > would be very inefficient in case of updating multiple documents. > > Hence I propose adding a new API that can update multiple documents using > [bulkUpdate|https://www.mongodb.com/docs/drivers/java/sync/current/usage-examples/bulkWrite/] > of Mongo on similar lines to the > [createOrUpdate|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentStore.java#L321] > API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
