[jira] [Updated] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3265:
--
Affects Version/s: 1.2.5
1.0.20
1.3.5
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
> Fix For: 1.3.6
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:132)
> ... 32 more
> testURILiteral(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.005 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path:
[jira] [Commented] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14726857#comment-14726857
]
Marcel Reutegger commented on OAK-3265:
---
Merged to 1.2: http://svn.apache.org/r1700713 and 1.0:
http://svn.apache.org/r1700714
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
> Fix For: 1.3.6
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:132)
> ... 32 more
> testURILiteral(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.005 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException:
[jira] [Created] (OAK-3332) Respect 'nsfixtures' in VersionGarbageCollectorIT
Marcel Reutegger created OAK-3332: - Summary: Respect 'nsfixtures' in VersionGarbageCollectorIT Key: OAK-3332 URL: https://issues.apache.org/jira/browse/OAK-3332 Project: Jackrabbit Oak Issue Type: Test Components: core, mongomk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.3.6 The test currently runs all available fixtures even if restricted by 'nsfixtures' system property. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3331) Support spellchecking multiple words
[ https://issues.apache.org/jira/browse/OAK-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-3331. -- Resolution: Fixed > Support spellchecking multiple words > > > Key: OAK-3331 > URL: https://issues.apache.org/jira/browse/OAK-3331 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.3.6 > > > Currently in oak-lucene it's only possible to spellcheck single words unless > a proper Analyzer is configured in the index definition while in Solr the > configuration has to be adjusted in order to provide multiple words > spellchecking, therefore it'd be good to adjust oak-lucene spellcheck > settings in order to be able to provide multiple word spellchecks and also to > tweak Solr configuration in order to have multiple words spellcheck > capability configured by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3334) Disable lease check in VersionGarbageCollectorIT
Marcel Reutegger created OAK-3334: - Summary: Disable lease check in VersionGarbageCollectorIT Key: OAK-3334 URL: https://issues.apache.org/jira/browse/OAK-3334 Project: Jackrabbit Oak Issue Type: Test Components: core, mongomk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.3.6 The test uses a virtual clock, which may interfere with the lease check and result in a System.exit(). The test should disable the check. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3312) [Blob GC] Test case for GC / OAK-3167
[ https://issues.apache.org/jira/browse/OAK-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3312: --- Fix Version/s: (was: 1.4) 1.3.6 > [Blob GC] Test case for GC / OAK-3167 > - > > Key: OAK-3312 > URL: https://issues.apache.org/jira/browse/OAK-3312 > Project: Jackrabbit Oak > Issue Type: Test > Components: blob, segmentmk >Reporter: Thomas Mueller >Assignee: Amit Jain > Fix For: 1.0.20, 1.3.6, 1.2.5 > > > OAK-3167 fixes the bug "Wrong time units for blobGcMaxAge are passed from > SegmentNodeStoreService". But there is no test case. > Without a good test case, we risk running into the same (or worse) problems > again, with each change of Oak in that area. And this is a really important > problem area: nobody wants to lose data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3281) Test failures on trunk: SolrIndexQueryTestIT.sql2
[
https://issues.apache.org/jira/browse/OAK-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14726951#comment-14726951
]
Tommaso Teofili commented on OAK-3281:
--
I managed to reproduce it and I think the problem is on the name() queries.
Under oak-solr-core/target you'll find a file named
oajopi.solr.query.SolrIndexQueryTestIT_sql2.txt which is the output which gets
compared with oak-core's sql2.txt.
As far as I can see name() queries do not work as expected in Solr (anymore?).
> Test failures on trunk: SolrIndexQueryTestIT.sql2
> -
>
> Key: OAK-3281
> URL: https://issues.apache.org/jira/browse/OAK-3281
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Labels: ci, jenkins
> Fix For: 1.3.6
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2}}
> fails regularly on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/350/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=integrationTesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.solr.query/SolrIndexQueryTestIT/sql2/
> {noformat}
> java.lang.Exception: Results in
> target/oajopi.solr.query.SolrIndexQueryTestIT_sql2.txt don't match expected
> results in
> file:/x1/jenkins/jenkins-slave/workspace/Apache%20Jackrabbit%20Oak%20matrix/jdk/jdk1.8.0_11/label/Ubuntu/nsfixtures/DOCUMENT_RDB/profile/integrationTesting/oak-core/target/oak-core-1.4-SNAPSHOT-tests.jar!/org/apache/jackrabbit/oak/query/sql2.txt;
> compare the files for details
> at
> org.apache.jackrabbit.oak.query.AbstractQueryTest.test(AbstractQueryTest.java:232)
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2(SolrIndexQueryTestIT.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3333) SplitOperations purges _commitRoot entries too eagerly
Marcel Reutegger created OAK-: - Summary: SplitOperations purges _commitRoot entries too eagerly Key: OAK- URL: https://issues.apache.org/jira/browse/OAK- Project: Jackrabbit Oak Issue Type: Bug Components: core, mongomk Affects Versions: 1.2, 1.0.12, 1.3.5 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.3.6 OAK-2528 introduced purging of _commitRoot entries without associated local changes on the document. Those _commitRoot entries are created when a child nodes is added and the _children flag is touched on the parent. The purge operation is too eager and removes all such entries, which may result in an undetected hierarchy conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3334) Disable lease check in VersionGarbageCollectorIT
[ https://issues.apache.org/jira/browse/OAK-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3334. --- Resolution: Fixed Done in trunk: http://svn.apache.org/r1700741 > Disable lease check in VersionGarbageCollectorIT > > > Key: OAK-3334 > URL: https://issues.apache.org/jira/browse/OAK-3334 > Project: Jackrabbit Oak > Issue Type: Test > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.3.6 > > > The test uses a virtual clock, which may interfere with the lease check and > result in a System.exit(). The test should disable the check. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3290) Revision gc blocks repository shutdown
[ https://issues.apache.org/jira/browse/OAK-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3290: --- Issue Type: Improvement (was: Sub-task) Parent: (was: OAK-2849) > Revision gc blocks repository shutdown > -- > > Key: OAK-3290 > URL: https://issues.apache.org/jira/browse/OAK-3290 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: cleanup, compaction, gc > Fix For: 1.0.20, 1.3.6, 1.2.5 > > > Shutting down the repository while revision gc is running might block for a > long time until either compaction estimation/compaction or clean up has > finished. We should provide a way to interrupt those operations for a timely > shut down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3331) Support spellchecking multiple words
Tommaso Teofili created OAK-3331: Summary: Support spellchecking multiple words Key: OAK-3331 URL: https://issues.apache.org/jira/browse/OAK-3331 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene, solr Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.3.6 Currently in oak-lucene it's only possible to spellcheck single words unless a proper Analyzer is configured in the index definition while in Solr the configuration has to be adjusted in order to provide multiple words spellchecking, therefore it'd be good to adjust oak-lucene spellcheck settings in order to be able to provide multiple word spellchecks and also to tweak Solr configuration in order to have multiple words spellcheck capability configured by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14726949#comment-14726949
]
Thomas Mueller commented on OAK-3265:
-
NodeNameTest#testPathLiteral: I think I can fix this in Oak (running tests now).
NodeLocalNameTest (testStringLiteralInvalidName and testURILiteral): They
expect the query to work, but return no rows, even thought the path is invalid.
However, the same tests in NodeNameTest expect the query to fail, because of
the invalid path. So I think this is a problem with the test.
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Fix For: 1.3.6
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
>
[jira] [Updated] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3265:
Fix Version/s: 1.2.5
1.0.20
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:132)
> ... 32 more
> testURILiteral(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.005 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a
[jira] [Assigned] (OAK-3312) [Blob GC] Test case for GC / OAK-3167
[ https://issues.apache.org/jira/browse/OAK-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain reassigned OAK-3312: -- Assignee: Amit Jain > [Blob GC] Test case for GC / OAK-3167 > - > > Key: OAK-3312 > URL: https://issues.apache.org/jira/browse/OAK-3312 > Project: Jackrabbit Oak > Issue Type: Test > Components: blob, segmentmk >Reporter: Thomas Mueller >Assignee: Amit Jain > Fix For: 1.4, 1.0.20, 1.2.5 > > > OAK-3167 fixes the bug "Wrong time units for blobGcMaxAge are passed from > SegmentNodeStoreService". But there is no test case. > Without a good test case, we risk running into the same (or worse) problems > again, with each change of Oak in that area. And this is a really important > problem area: nobody wants to lose data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3332) Respect 'nsfixtures' in VersionGarbageCollectorIT
[ https://issues.apache.org/jira/browse/OAK-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3332. --- Resolution: Fixed Done in trunk: http://svn.apache.org/r1700724 > Respect 'nsfixtures' in VersionGarbageCollectorIT > - > > Key: OAK-3332 > URL: https://issues.apache.org/jira/browse/OAK-3332 > Project: Jackrabbit Oak > Issue Type: Test > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.3.6 > > > The test currently runs all available fixtures even if restricted by > 'nsfixtures' system property. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3265:
--
Assignee: Thomas Mueller
[~tmueller], can you have a look at this? I think the tests fail because of
OAK-2634.
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Fix For: 1.3.6
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:132)
> ... 32 more
> testURILiteral(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.005 sec <<< ERROR!
>
[jira] [Comment Edited] (OAK-3156) Lucene suggestions index definition can't be restricted to a specific type of node
[
https://issues.apache.org/jira/browse/OAK-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14721279#comment-14721279
]
Vikas Saurabh edited comment on OAK-3156 at 9/2/15 7:12 AM:
Attaching a slightly modified [version|^OAK-3156-take2.patch] of the previous
patch.
[~teofili], the failures were there because I had set path=null for virtual
rows. This patch sets '/' for virtual rows (subsequently I undid removal of
PathCursor wrapping).
[~tmueller], I'm not sure if we should update virtual row documentation to say
that virtual rows need to set path or should we fix other places in code which
expect path despite a row being virtual.
Alternatively, fixing test cases to not user {{jcr:path='/'}} condition works
too for 4 cases. The others result in NPE in {{SameNodeImpl.evaluate}} where it
calls equals on {{currentPath}} which is null. Fixing that is fairly simple to
change {{SelectorImpl}} to export 'virtual'-ity of current row and use that to
evaluate correctly.
That being said, there are a lot of places where current path is being referred
to - while the tests might not be failing, but I'm not too confident if it's
fine to have {{null}} jcr:path for rows. [~tmueller] what do you suggest?
was (Author: catholicon):
Attaching a slightly modified [version|^OAK-3156-take2.patch] of the previous
patch.
[~teofili], the failures were there because I had set path=null for virtual
rows. This patch sets '/' for virtual rows (subsequently I undid removal of
PathCursor wrapping).
[~tmueller], I'm not sure if we should update virtual row documentation to say
that virtual rows need to set path or should we fix other places in code which
expect path despite a row being virtual.
> Lucene suggestions index definition can't be restricted to a specific type of
> node
> --
>
> Key: OAK-3156
> URL: https://issues.apache.org/jira/browse/OAK-3156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Tommaso Teofili
> Attachments: LuceneIndexSuggestionTest.java, OAK-3156-take2.patch,
> OAK-3156.patch
>
>
> While performing a suggestor query like
> {code}
> SELECT [rep:suggest()] as suggestion FROM [nt:unstructured] WHERE
> suggest('foo')
> {code}
> Suggestor does not provide any result. In current implementation,
> [suggestions|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Suggestions]
> in Oak work only for index definitions for {{nt:base}} nodetype.
> So, an index definition like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> works, but if we change nodetype to {{nt:unstructured}} like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> , it won't work.
> The issue is that suggestor implementation essentially is passing a pseudo
> row with path=/.:
> {code:title=LucenePropertyIndex.java}
> private boolean loadDocs() {
> ...
> queue.add(new LuceneResultRow(suggestedWords));
> ...
> {code}
> and
> {code:title=LucenePropertyIndex.java}
> LuceneResultRow(Iterable suggestWords) {
> this.path = "/";
> this.score = 1.0d;
> this.suggestWords = suggestWords;
> }
> {code}
> Due to path being set to "/", {{SelectorImpl}} later filters out the result
> as {{rep:root}} (primary type of "/") isn't a {{nt:unstructured}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3305) Self recovering instance may not see all changes
[ https://issues.apache.org/jira/browse/OAK-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3305. --- Resolution: Fixed Fixed in trunk: http://svn.apache.org/r1700709 > Self recovering instance may not see all changes > > > Key: OAK-3305 > URL: https://issues.apache.org/jira/browse/OAK-3305 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.0, 1.2, 1.3.4 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: candidate_oak_1_0, candidate_oak_1_2, resilience > Fix For: 1.3.6 > > > When a DocumentNodeStore instance is killed and restarted, the _lastRev > recovery mechanism is triggered on startup. It may happen that the restarted > instance does not see all changes that were recovered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3305) Self recovering instance may not see all changes
[ https://issues.apache.org/jira/browse/OAK-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3305: -- Labels: candidate_oak_1_0 candidate_oak_1_2 resilience (was: resilience) > Self recovering instance may not see all changes > > > Key: OAK-3305 > URL: https://issues.apache.org/jira/browse/OAK-3305 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.0, 1.2, 1.3.4 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: candidate_oak_1_0, candidate_oak_1_2, resilience > Fix For: 1.3.6 > > > When a DocumentNodeStore instance is killed and restarted, the _lastRev > recovery mechanism is triggered on startup. It may happen that the restarted > instance does not see all changes that were recovered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14726853#comment-14726853
]
Marcel Reutegger commented on OAK-3265:
---
These failures are now also on 1.2 and 1.0. Changes for OAK-2634 were merged to
those branches.
I will merge the update of the known issues list.
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Michael Dürig
> Fix For: 1.3.6
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:132)
> ... 32 more
> testURILiteral(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.005 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException:
[jira] [Created] (OAK-3329) TarMK cleanup blocks writers
Michael Dürig created OAK-3329:
--
Summary: TarMK cleanup blocks writers
Key: OAK-3329
URL: https://issues.apache.org/jira/browse/OAK-3329
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segmentmk
Reporter: Michael Dürig
TarMK cleanup exclusively locks the {{FileStore}}, which causes concurrent
writers to block until cleanup finished. Initially cleanup was expected to be
reasonably fast, however I have seen it taking dozens of minutes under certain
circumstances (most likely many tar files with many small segments, aka
OAK-2896).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3281) Test failures on trunk: SolrIndexQueryTestIT.sql2
[
https://issues.apache.org/jira/browse/OAK-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14726887#comment-14726887
]
Thomas Mueller commented on OAK-3281:
-
http://svn.apache.org/r1700495 (improved test output)
http://svn.apache.org/r1700715 (re-enabled the test)
> Test failures on trunk: SolrIndexQueryTestIT.sql2
> -
>
> Key: OAK-3281
> URL: https://issues.apache.org/jira/browse/OAK-3281
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Labels: ci, jenkins
> Fix For: 1.3.6
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2}}
> fails regularly on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/350/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=integrationTesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.solr.query/SolrIndexQueryTestIT/sql2/
> {noformat}
> java.lang.Exception: Results in
> target/oajopi.solr.query.SolrIndexQueryTestIT_sql2.txt don't match expected
> results in
> file:/x1/jenkins/jenkins-slave/workspace/Apache%20Jackrabbit%20Oak%20matrix/jdk/jdk1.8.0_11/label/Ubuntu/nsfixtures/DOCUMENT_RDB/profile/integrationTesting/oak-core/target/oak-core-1.4-SNAPSHOT-tests.jar!/org/apache/jackrabbit/oak/query/sql2.txt;
> compare the files for details
> at
> org.apache.jackrabbit.oak.query.AbstractQueryTest.test(AbstractQueryTest.java:232)
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2(SolrIndexQueryTestIT.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3330) FileStore lock contention with concurrent writers
[
https://issues.apache.org/jira/browse/OAK-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14726900#comment-14726900
]
Michael Dürig commented on OAK-3330:
Note that his also impacts compaction as this is just another thread writing to
the repository.
> FileStore lock contention with concurrent writers
> -
>
> Key: OAK-3330
> URL: https://issues.apache.org/jira/browse/OAK-3330
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction
>
> Concurrently writing to the file store can lead to a sever lock contention in
> {{FileStore#readSegment}}. That method searches the current {{TarWriter}}
> instance for the segment once it could not be found in any of the
> {{TarReader}} instances. This is the point where synchronizes on the
> {{FileStore}} instance, which leads to the contention.
> The effect is only observable once the segment cache becomes full and reads
> actually need to go to the file store. Thus a possible improvement could be
> to pin segments from the current tar writer to the cache. Alternatively we
> could try to ease locking by employing read/write locks where possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3330) FileStore lock contention with concurrent writers
Michael Dürig created OAK-3330:
--
Summary: FileStore lock contention with concurrent writers
Key: OAK-3330
URL: https://issues.apache.org/jira/browse/OAK-3330
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segmentmk
Reporter: Michael Dürig
Assignee: Michael Dürig
Concurrently writing to the file store can lead to a sever lock contention in
{{FileStore#readSegment}}. That method searches the current {{TarWriter}}
instance for the segment once it could not be found in any of the {{TarReader}}
instances. This is the point where synchronizes on the {{FileStore}} instance,
which leads to the contention.
The effect is only observable once the segment cache becomes full and reads
actually need to go to the file store. Thus a possible improvement could be to
pin segments from the current tar writer to the cache. Alternatively we could
try to ease locking by employing read/write locks where possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3341) lucene technical debt
[ https://issues.apache.org/jira/browse/OAK-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-3341: --- Fix Version/s: (was: 1.4) 1.3.9 > lucene technical debt > - > > Key: OAK-3341 > URL: https://issues.apache.org/jira/browse/OAK-3341 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Daniel Hasler > Fix For: 1.3.9 > > > As discussed bilaterally grouping the technical debt for Lucene in this issue > for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3340) mongomk technical debt
[ https://issues.apache.org/jira/browse/OAK-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-3340: --- Fix Version/s: (was: 1.4) 1.3.9 > mongomk technical debt > --- > > Key: OAK-3340 > URL: https://issues.apache.org/jira/browse/OAK-3340 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Daniel Hasler > Fix For: 1.3.9 > > > As discussed bilaterally grouping the technical debt for MongoMK in this > issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3340) mongomk technical debt
Daniel Hasler created OAK-3340: -- Summary: mongomk technical debt Key: OAK-3340 URL: https://issues.apache.org/jira/browse/OAK-3340 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk Reporter: Daniel Hasler Fix For: 1.3.8 As discussed bilaterally grouping the technical debt for MongoMK in this issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3341) lucene technical debt
Daniel Hasler created OAK-3341: -- Summary: lucene technical debt Key: OAK-3341 URL: https://issues.apache.org/jira/browse/OAK-3341 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene Reporter: Daniel Hasler Fix For: 1.4 As discussed bilaterally grouping the technical debt for Lucene in this issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3340) mongomk technical debt
[ https://issues.apache.org/jira/browse/OAK-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Hasler updated OAK-3340: --- Fix Version/s: (was: 1.3.8) 1.4 > mongomk technical debt > --- > > Key: OAK-3340 > URL: https://issues.apache.org/jira/browse/OAK-3340 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Daniel Hasler > Fix For: 1.4 > > > As discussed bilaterally grouping the technical debt for MongoMK in this > issue for easier tracking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3310) Write operations on Property do not check checked-out state of Node
[ https://issues.apache.org/jira/browse/OAK-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3310: Fix Version/s: 1.2.5 > Write operations on Property do not check checked-out state of Node > --- > > Key: OAK-3310 > URL: https://issues.apache.org/jira/browse/OAK-3310 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.3.6, 1.2.5 > > Attachments: OAK-3310.diff > > > Write operations on Property do not check the checked-out state. The same is > true for Node.setProperty(..., null). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3337) CIHelper methods related to travis outdated
[ https://issues.apache.org/jira/browse/OAK-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3337: -- Component/s: (was: commons) core > CIHelper methods related to travis outdated > --- > > Key: OAK-3337 > URL: https://issues.apache.org/jira/browse/OAK-3337 > Project: Jackrabbit Oak > Issue Type: Test > Components: core >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.0.20, 1.3.6, 1.2.5 > > > The travis related methods in CIHelper are outdated. The travis builds do not > use the PROFILE environment variable anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3337) CIHelper method related to travis outdated
[ https://issues.apache.org/jira/browse/OAK-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3337: -- Fix Version/s: 1.2.5 1.3.6 1.0.20 > CIHelper method related to travis outdated > -- > > Key: OAK-3337 > URL: https://issues.apache.org/jira/browse/OAK-3337 > Project: Jackrabbit Oak > Issue Type: Test > Components: commons >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.0.20, 1.3.6, 1.2.5 > > > The travis related methods in CIHelper are outdated. The travis builds do not > use the PROFILE environment variable anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-1611) Support also LBHttpSolrServer in RemoteSolrServerProvider
[ https://issues.apache.org/jira/browse/OAK-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-1611. -- Resolution: Won't Fix Fix Version/s: (was: 1.4) resolving as won't fix since we don't have yet a use case for LB Solr server > Support also LBHttpSolrServer in RemoteSolrServerProvider > - > > Key: OAK-1611 > URL: https://issues.apache.org/jira/browse/OAK-1611 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > > Solr's LBHttpSolrServer can do software load balancing between Solr instances > (should be all replicas with the same underlying index to work here) and it'd > be good to provide support for that in RemoteSolrServerProvider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3337) CIHelper method related to travis outdated
Marcel Reutegger created OAK-3337: - Summary: CIHelper method related to travis outdated Key: OAK-3337 URL: https://issues.apache.org/jira/browse/OAK-3337 Project: Jackrabbit Oak Issue Type: Test Components: commons Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor The travis related methods in CIHelper are outdated. The travis builds do not use the PROFILE environment variable anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727202#comment-14727202
]
Thomas Mueller commented on OAK-3265:
-
http://svn.apache.org/r1700767 (1.0 and 1.2 branch)
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:132)
> ... 32 more
> testURILiteral(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.005 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException:
[jira] [Created] (OAK-3338) Deprecate CIHelper travis methods with profile
Marcel Reutegger created OAK-3338: - Summary: Deprecate CIHelper travis methods with profile Key: OAK-3338 URL: https://issues.apache.org/jira/browse/OAK-3338 Project: Jackrabbit Oak Issue Type: Sub-task Components: commons Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.0.20, 1.3.6, 1.2.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3337) CIHelper methods related to travis outdated
[ https://issues.apache.org/jira/browse/OAK-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3337: -- Summary: CIHelper methods related to travis outdated (was: CIHelper method related to travis outdated) > CIHelper methods related to travis outdated > --- > > Key: OAK-3337 > URL: https://issues.apache.org/jira/browse/OAK-3337 > Project: Jackrabbit Oak > Issue Type: Test > Components: commons >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.0.20, 1.3.6, 1.2.5 > > > The travis related methods in CIHelper are outdated. The travis builds do not > use the PROFILE environment variable anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3330) FileStore lock contention with concurrent writers
[
https://issues.apache.org/jira/browse/OAK-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727206#comment-14727206
]
Michael Dürig commented on OAK-3330:
Caching all segments of the current tar writer improves the situation quite a
bit. With below configuration of {{SegmentCompactionIT}} I was able to write
2.5 GB of content vs. 5.8 GB of content with the cache. In the former case the
{{FileStore}} monitor was fully contented while in the latter no lock was
contended more then 4%.
{code}
private volatile int lockWaitTime = 60;
private volatile int maxReaders = 10;
private volatile int maxWriters = 16;
private volatile long maxStoreSize = 1200L;
private volatile int maxBlobSize = 1;
private volatile int maxStringSize = 1;
private volatile int maxReferences = 10;
private volatile int maxWriteOps = 1;
private volatile int maxNodeCount = 1000;
private volatile int maxPropertyCount = 1000;
private volatile int nodeRemoveRatio = 10;
private volatile int propertyRemoveRatio = 10;
private volatile int nodeAddRatio = 40;
private volatile int addStringRatio = 20;
private volatile int addBinaryRatio = 0;
private volatile int compactionInterval = 120;
{code}
> FileStore lock contention with concurrent writers
> -
>
> Key: OAK-3330
> URL: https://issues.apache.org/jira/browse/OAK-3330
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction
>
> Concurrently writing to the file store can lead to a sever lock contention in
> {{FileStore#readSegment}}. That method searches the current {{TarWriter}}
> instance for the segment once it could not be found in any of the
> {{TarReader}} instances. This is the point where synchronizes on the
> {{FileStore}} instance, which leads to the contention.
> The effect is only observable once the segment cache becomes full and reads
> actually need to go to the file store. Thus a possible improvement could be
> to pin segments from the current tar writer to the cache. Alternatively we
> could try to ease locking by employing read/write locks where possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3330) FileStore lock contention with concurrent writers
[
https://issues.apache.org/jira/browse/OAK-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-3330:
---
Attachment: OAK-3330.patch
Patch with the cache I used for above test. This is very raw still. It is
carefully crafted in a way not to duplicate the underlying data of segments
even though the segment cache in {{SegmentTracker}} and the one in
{{FileStore}} might contain the same (equals) segment but a different instance
(!=).
> FileStore lock contention with concurrent writers
> -
>
> Key: OAK-3330
> URL: https://issues.apache.org/jira/browse/OAK-3330
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: compaction
> Attachments: OAK-3330.patch
>
>
> Concurrently writing to the file store can lead to a sever lock contention in
> {{FileStore#readSegment}}. That method searches the current {{TarWriter}}
> instance for the segment once it could not be found in any of the
> {{TarReader}} instances. This is the point where synchronizes on the
> {{FileStore}} instance, which leads to the contention.
> The effect is only observable once the segment cache becomes full and reads
> actually need to go to the file store. Thus a possible improvement could be
> to pin segments from the current tar writer to the cache. Alternatively we
> could try to ease locking by employing read/write locks where possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3156) Lucene suggestions index definition can't be restricted to a specific type of node
[
https://issues.apache.org/jira/browse/OAK-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727214#comment-14727214
]
Thomas Mueller commented on OAK-3156:
-
I'm not sure if we need to support xpath (and if yes: how). Also, I'm not sure
if we need to support "select ... from [nt:unstructured]" with "suggest"
queries. Couldn't you just use "from [nt:base]"?
I guess we need to decide what we want to support, and why. One reason could be
compatibility with Jackrabbit 2.x. As for xpath support: in my view, xpath is
the "high level" query language, and sql-2 is the "low level" language. For
"suggest" queries, those don't return nodes really, do we need to support
xpath? Why?
> Lucene suggestions index definition can't be restricted to a specific type of
> node
> --
>
> Key: OAK-3156
> URL: https://issues.apache.org/jira/browse/OAK-3156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Tommaso Teofili
> Attachments: LuceneIndexSuggestionTest.java, OAK-3156-take2.patch,
> OAK-3156.patch
>
>
> While performing a suggestor query like
> {code}
> SELECT [rep:suggest()] as suggestion FROM [nt:unstructured] WHERE
> suggest('foo')
> {code}
> Suggestor does not provide any result. In current implementation,
> [suggestions|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Suggestions]
> in Oak work only for index definitions for {{nt:base}} nodetype.
> So, an index definition like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> works, but if we change nodetype to {{nt:unstructured}} like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> , it won't work.
> The issue is that suggestor implementation essentially is passing a pseudo
> row with path=/.:
> {code:title=LucenePropertyIndex.java}
> private boolean loadDocs() {
> ...
> queue.add(new LuceneResultRow(suggestedWords));
> ...
> {code}
> and
> {code:title=LucenePropertyIndex.java}
> LuceneResultRow(Iterable suggestWords) {
> this.path = "/";
> this.score = 1.0d;
> this.suggestWords = suggestWords;
> }
> {code}
> Due to path being set to "/", {{SelectorImpl}} later filters out the result
> as {{rep:root}} (primary type of "/") isn't a {{nt:unstructured}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3338) Deprecate CIHelper travis methods with profile
[ https://issues.apache.org/jira/browse/OAK-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3338. --- Resolution: Fixed Deprecated methods in trunk: http://svn.apache.org/r1700769 Merged into 1.2 branch: http://svn.apache.org/r1700771 and 1.0 branch: http://svn.apache.org/r1700772 > Deprecate CIHelper travis methods with profile > --- > > Key: OAK-3338 > URL: https://issues.apache.org/jira/browse/OAK-3338 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: commons >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.0.20, 1.3.6, 1.2.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727057#comment-14727057
]
Thomas Mueller commented on OAK-3265:
-
As for NodeLocalNameTest#testPathLiteral, I can make it work, but this will
break Node*Local*NameTest#testPathLiteral which uses a different assertion...
So that one I would have to add to the ignore list as well. In theory, I think
we should change the tests, but that would be more work as this would require
us to change Jackrabbit 2.x. It doesn't seem to be worth the effort.
Proposed patch:
{noformat}
### Eclipse Workspace Patch 1.0
#P oak-core
Index: src/main/java/org/apache/jackrabbit/oak/query/ast/NodeNameImpl.java
===
--- src/main/java/org/apache/jackrabbit/oak/query/ast/NodeNameImpl.java
(revision 1700719)
+++ src/main/java/org/apache/jackrabbit/oak/query/ast/NodeNameImpl.java
(working copy)
@@ -129,8 +129,13 @@
name = ISO9075.decode(name);
// normalize paths (./name > name)
name = PropertyValues.getOakPath(name, query.getNamePathMapper());
-
-if (name.startsWith("[") && !name.endsWith("]")) {
+if (PathUtils.isAbsolute(name)) {
+throw new IllegalArgumentException("Not a valid JCR name: "
++ name + " (absolute paths are not names)");
+} else if (PathUtils.getDepth(name) > 1) {
+throw new IllegalArgumentException("Not a valid JCR name: "
++ name + " (relative path with depth > 1 are not names)");
+} else if (name.startsWith("[") && !name.endsWith("]")) {
return null;
} else if (!JcrNameParser.validate(name)) {
return null;
#P oak-jcr
Index: pom.xml
===
--- pom.xml (revision 1700719)
+++ pom.xml (working copy)
@@ -106,8 +106,8 @@
org.apache.jackrabbit.test.api.query.SQLJoinTest#testJoinFilterPrimaryType
org.apache.jackrabbit.test.api.query.SQLJoinTest#testJoinSNS
org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest#testStringLiteralInvalidName
+
org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest#testPathLiteral
org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest#testURILiteral
- org.apache.jackrabbit.test.api.query.qom.NodeNameTest#testPathLiteral
org.apache.jackrabbit.core.query.ExcerptTest#testMoreTextDotsAtEnd
org.apache.jackrabbit.core.query.ExcerptTest#testMoreTextDotsAtStart
{noformat}
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
[jira] [Updated] (OAK-2712) Possible null-dereference when calling ItemImpl#perform
[
https://issues.apache.org/jira/browse/OAK-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-2712:
Affects Version/s: 1.2.4
> Possible null-dereference when calling ItemImpl#perform
> ---
>
> Key: OAK-2712
> URL: https://issues.apache.org/jira/browse/OAK-2712
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.4, 1.0.19
>Reporter: angela
>Assignee: angela
> Labels: technical_debt
> Fix For: 1.3.0, 1.2.5
>
>
> FindBugs complains about usages of ItemImpl#perform that is annotated with
> {{@CheckForNull}} but callers expecting a non-null return value most
> prominently in NodeImpl
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727149#comment-14727149
]
Thomas Mueller commented on OAK-3265:
-
> Alternatively we could indeed change the test and add the failing test in
> Jackrabbit 2.x on its known issues list.
Your are right, I didn't think about this option. I will try to do that.
But first, I'm trying to make the tests work.
http://svn.apache.org/r1700760
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
>
[jira] [Commented] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727326#comment-14727326 ] Marcel Reutegger commented on OAK-3042: --- Turning the data of a test run into a graph shows something like this: !commit-graph.png|with=100%! Every now and then the commit rate drops to zero for a session and sometimes only one session makes progress. > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > Attachments: commit-graph.png > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1744) GQL queries with "jcr:primaryType='x'" don't use the node type index
[ https://issues.apache.org/jira/browse/OAK-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-1744: Fix Version/s: (was: 1.3.6) 1.3.7 > GQL queries with "jcr:primaryType='x'" don't use the node type index > > > Key: OAK-1744 > URL: https://issues.apache.org/jira/browse/OAK-1744 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.3.7 > > > GQL queries (org.apache.jackrabbit.commons.query.GQL) with type restrictions > are converted to the XPath condition "jcr:primaryType = 'x'". This conditions > is not currently interpreted as a regular node type restriction in the query > engine or the node type index, as one would expect. > Such restrictions could still be processed efficiently using the property > index on "jcr:primaryType", but if that one is disabled (by setting the cost > manually very high, as it is done now), then such queries don't use the > expected index. > I'm not sure yet where this should be best fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2037) Define standards for plan output
[ https://issues.apache.org/jira/browse/OAK-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2037: Fix Version/s: (was: 1.3.6) 1.3.7 > Define standards for plan output > > > Key: OAK-2037 > URL: https://issues.apache.org/jira/browse/OAK-2037 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Justin Edelson >Assignee: Thomas Mueller >Priority: Minor > Labels: tooling > Fix For: 1.3.7 > > > Currently, the syntax for the plan output is chaotic as it varies > significantly from index to index. Whereas some of this is expected - each > index type will have different data to output, Oak should provide some > standards about how a plan will appear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1221) Query fails unexpectedly when property conversion is not possible for joins and "in(...)"
[ https://issues.apache.org/jira/browse/OAK-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-1221: Fix Version/s: (was: 1.3.6) 1.3.7 > Query fails unexpectedly when property conversion is not possible for joins > and "in(...)" > - > > Key: OAK-1221 > URL: https://issues.apache.org/jira/browse/OAK-1221 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.3.7 > > > The same as for OAK-1171, however the fix there only solves the problem for > comparisons but not joins and conditions of the form "in(x, y)" (the two > other places where values are converted). > I guess those cases are less common than OAK-1171, but it should be quite > easy to come up with a simple test case. I will try to do that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2679) Query engine: cache execution plans
[ https://issues.apache.org/jira/browse/OAK-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2679: Fix Version/s: (was: 1.3.6) 1.3.7 > Query engine: cache execution plans > --- > > Key: OAK-2679 > URL: https://issues.apache.org/jira/browse/OAK-2679 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, query >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: performance > Fix For: 1.3.7 > > Attachments: 0001-OAK-2679-Reduce-execution-plan-overhead_0.2.patch, > OAK-2679.patch, executionplancache.patch > > > If there are many indexes, preparing a query can take a long time, in > relation to executing the query. > The query execution plans can be cached. The cache should be invalidated if > there are new indexes, or indexes are changed; a simple solution might be to > use a timeout, and / or a manual cache clean via JMX or so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3140) DataStore / BlobStore: add a method to pass a "type" when writing
[ https://issues.apache.org/jira/browse/OAK-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-3140: Fix Version/s: (was: 1.3.6) 1.3.7 > DataStore / BlobStore: add a method to pass a "type" when writing > - > > Key: OAK-3140 > URL: https://issues.apache.org/jira/browse/OAK-3140 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: blob >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Labels: performance > Fix For: 1.3.7 > > > Currently, the BlobStore interface has a method "String writeBlob(InputStream > in)". This issue is about adding a new method "String writeBlob(String type, > InputStream in)", for the following reasons (in no particular order): > * Store some binaries (for example Lucene index files) in a different place, > in order to safely and quickly run garbage collection just on those files. > * Store some binaries in a slow, some in a fast storage or location. > * Disable calculating the content hash (de-duplication) for some binaries. > * Store some binaries in a shared storage (for fast cross-repository > copying), and some in local storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2644: Fix Version/s: (was: 1.3.6) 1.3.7 > Lift the 150 character limit on node names > -- > > Key: OAK-2644 > URL: https://issues.apache.org/jira/browse/OAK-2644 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0 >Reporter: Felix Meschberger >Assignee: Thomas Mueller > Fix For: 1.3.8 > > > Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the > length of 150 characters for item names in Oak. > This limit seems to be based upon a limitation in the MongoDB MK > implementation because MongoDB has a limit of 1024 bytes (I think) for > indexable properties. > I think this limitation is highly unexpected and seems to be largeyl > undocumented. For previous users of Jackrabbit it should probably at least be > documented on the [Backwards > Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. > The main problem, though, I have with this limit is, that it is based on a > limitation of a particular MK implementation and hits through the full stack. > I would have rather expected such a persistence limitation to be fully hidden > and handled inside the MK implementation. > Granted this limitation does not seem to violate the JCR 2.1 specification > which clearly states in section 3.2.4 Naming Restrictions: > bq. This definition of JCR name represents the least restrictive set of > constraints permitted for the naming of items and other entities. A > repository may further restrict the names of entities to a subset of JCR > names and in most cases is encouraged to do so. > and > bq. A writable repository may enforce any implementation-specific constraint > by causing an exception to be thrown on an invalid JCR write method call. > Still I think it is a questionable limitation for a generic repository where > such names may be auto-generated and thus be quite long depending on the use > case. > I understand this may be hard to fix but would still be happy to be able to > have (virtually) unlimited name length again as it was the case in Jackrabbit > 2. > Thanks. > See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2644: Fix Version/s: (was: 1.3.7) 1.3.8 > Lift the 150 character limit on node names > -- > > Key: OAK-2644 > URL: https://issues.apache.org/jira/browse/OAK-2644 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0 >Reporter: Felix Meschberger >Assignee: Thomas Mueller > Fix For: 1.3.8 > > > Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the > length of 150 characters for item names in Oak. > This limit seems to be based upon a limitation in the MongoDB MK > implementation because MongoDB has a limit of 1024 bytes (I think) for > indexable properties. > I think this limitation is highly unexpected and seems to be largeyl > undocumented. For previous users of Jackrabbit it should probably at least be > documented on the [Backwards > Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. > The main problem, though, I have with this limit is, that it is based on a > limitation of a particular MK implementation and hits through the full stack. > I would have rather expected such a persistence limitation to be fully hidden > and handled inside the MK implementation. > Granted this limitation does not seem to violate the JCR 2.1 specification > which clearly states in section 3.2.4 Naming Restrictions: > bq. This definition of JCR name represents the least restrictive set of > constraints permitted for the naming of items and other entities. A > repository may further restrict the names of entities to a subset of JCR > names and in most cases is encouraged to do so. > and > bq. A writable repository may enforce any implementation-specific constraint > by causing an exception to be thrown on an invalid JCR write method call. > Still I think it is a questionable limitation for a generic repository where > such names may be auto-generated and thus be quite long depending on the use > case. > I understand this may be hard to fix but would still be happy to be able to > have (virtually) unlimited name length again as it was the case in Jackrabbit > 2. > Thanks. > See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3339) Logging in and out many sessions leads to high memory consumption
[
https://issues.apache.org/jira/browse/OAK-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3339:
Fix Version/s: (was: 1.1.0)
1.0.20
> Logging in and out many sessions leads to high memory consumption
> --
>
> Key: OAK-3339
> URL: https://issues.apache.org/jira/browse/OAK-3339
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Fix For: 1.0.20
>
>
> See http://markmail.org/message/b65g2suyhhbhnefw for the report and
> {{org.apache.jackrabbit.oak.benchmark.LoginLogoutUserTest}} demonstrating the
> issue. Running that benchmark with 128M heap leads to memory pressure and the
> test performing an order of magnitude worse than when running with 1G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3339) Logging in and out many sessions leads to high memory consumption
[
https://issues.apache.org/jira/browse/OAK-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-3339.
-
Resolution: Fixed
> Logging in and out many sessions leads to high memory consumption
> --
>
> Key: OAK-3339
> URL: https://issues.apache.org/jira/browse/OAK-3339
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Fix For: 1.0.20
>
>
> See http://markmail.org/message/b65g2suyhhbhnefw for the report and
> {{org.apache.jackrabbit.oak.benchmark.LoginLogoutUserTest}} demonstrating the
> issue. Running that benchmark with 128M heap leads to memory pressure and the
> test performing an order of magnitude worse than when running with 1G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727326#comment-14727326 ] Marcel Reutegger edited comment on OAK-3042 at 9/2/15 1:28 PM: --- Turning the data of a test run into a stacked graph shows something like this: !commit-graph.png|with=100%! Every now and then the commit rate drops to zero for a session and sometimes only one session makes progress. was (Author: mreutegg): Turning the data of a test run into a graph shows something like this: !commit-graph.png|with=100%! Every now and then the commit rate drops to zero for a session and sometimes only one session makes progress. > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > Attachments: commit-graph.png > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-321) Deref (jcr:deref) support
[
https://issues.apache.org/jira/browse/OAK-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-321:
---
Fix Version/s: (was: 1.3.6)
1.3.7
> Deref (jcr:deref) support
> -
>
> Key: OAK-321
> URL: https://issues.apache.org/jira/browse/OAK-321
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: jcr, query
>Reporter: Alex Parvulescu
>Assignee: Thomas Mueller
> Labels: CI
> Fix For: 1.3.7
>
>
> Test class DerefTest.
> For now there are just parse exceptions:
> {noformat}
> javax.jcr.query.InvalidQueryException: java.text.ParseException: Query:
> testroot/people/jcr:deref((*)@worksfor, '*'); expected:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2808: Fix Version/s: (was: 1.3.6) 1.3.7 > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller > Labels: datastore, performance > Fix For: 1.3.7 > > Attachments: copyonread-stats.png > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3265) Test failures: NodeLocalNameTest, NodeNameTest
[
https://issues.apache.org/jira/browse/OAK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727075#comment-14727075
]
Marcel Reutegger commented on OAK-3265:
---
bq. In theory, I think we should change the tests, but that would be more work
as this would require us to change Jackrabbit 2.x.
Alternatively we could indeed change the test and add the failing test in
Jackrabbit 2.x on its known issues list.
> Test failures: NodeLocalNameTest, NodeNameTest
> --
>
> Key: OAK-3265
> URL: https://issues.apache.org/jira/browse/OAK-3265
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.3.5, 1.0.20, 1.2.5
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> Trunk's it fail for me:
> {noformat}
> testStringLiteralInvalidName(org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest)
> Time elapsed: 0.007 sec <<< ERROR!
> javax.jcr.query.InvalidQueryException: java.lang.IllegalArgumentException:
> Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.jcr.query.QueryManagerImpl.executeQuery(QueryManagerImpl.java:142)
> at
> org.apache.jackrabbit.oak.jcr.query.qom.QueryObjectModelImpl.execute(QueryObjectModelImpl.java:131)
> at
> org.apache.jackrabbit.test.api.query.qom.NodeLocalNameTest.testStringLiteralInvalidName(NodeLocalNameTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.IllegalArgumentException: Not a valid JCR path: [node1
> at
> org.apache.jackrabbit.oak.spi.query.PropertyValues.getOakPath(PropertyValues.java:405)
> at
> org.apache.jackrabbit.oak.query.ast.NodeNameImpl.getName(NodeNameImpl.java:131)
> at
> org.apache.jackrabbit.oak.query.ast.NodeLocalNameImpl.restrict(NodeLocalNameImpl.java:89)
> at
> org.apache.jackrabbit.oak.query.ast.ComparisonImpl.restrict(ComparisonImpl.java:184)
> at
> org.apache.jackrabbit.oak.query.ast.AndImpl.restrict(AndImpl.java:153)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.createFilter(SelectorImpl.java:389)
> at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.prepare(SelectorImpl.java:284)
> at org.apache.jackrabbit.oak.query.QueryImpl.prepare(QueryImpl.java:591)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:193)
> at
>
[jira] [Created] (OAK-3335) RepositorySidegrade has runtime dependency on jackrabbit-core
Julian Sedding created OAK-3335:
---
Summary: RepositorySidegrade has runtime dependency on
jackrabbit-core
Key: OAK-3335
URL: https://issues.apache.org/jira/browse/OAK-3335
Project: Jackrabbit Oak
Issue Type: Bug
Components: upgrade
Affects Versions: 1.3.5
Reporter: Julian Sedding
Assignee: Julian Sedding
Fix For: 1.3.6
It should be possible to run {{RepositorySidegrade}} from a runnable jar file
that does not embed {{jackrabbit-core}}. E.g. once {{RepositorySidegrade}} is
enabled in {{oak-run}}, it shoudl work in the variant that does not embed
jackrabbit-core.
OAK-3239 introduced a transitive runtime dependency from
{{RepositorySidegrade}} to {{RepositoryUpgrade}} (via static imports), which
has dependencies to classes in {{jackrabbit-core}}. This leads to failure with
a {{ClassNotFoundException}}.
Moving the constants and static method to {{RepositorySidegrade}} and importing
them in {{RepositoryUpgrade}} instead should resolve the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3312) [Blob GC] Test case for GC / OAK-3167
[ https://issues.apache.org/jira/browse/OAK-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-3312. Resolution: Fixed Added test cases for GC when no blobs should be deleted when the blobGcMaxAge param is not 0 and in the past. * trunk - http://svn.apache.org/r1700727 & http://svn.apache.org/r1700746 * 1.0 - http://svn.apache.org/r1700738 * 1.2 - http://svn.apache.org/r1700743 > [Blob GC] Test case for GC / OAK-3167 > - > > Key: OAK-3312 > URL: https://issues.apache.org/jira/browse/OAK-3312 > Project: Jackrabbit Oak > Issue Type: Test > Components: blob, segmentmk >Reporter: Thomas Mueller >Assignee: Amit Jain > Fix For: 1.0.20, 1.3.6, 1.2.5 > > > OAK-3167 fixes the bug "Wrong time units for blobGcMaxAge are passed from > SegmentNodeStoreService". But there is no test case. > Without a good test case, we risk running into the same (or worse) problems > again, with each change of Oak in that area. And this is a really important > problem area: nobody wants to lose data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr
Tommaso Teofili created OAK-3336: Summary: Abstract a full text index implementation to be extended by Lucene and Solr Key: OAK-3336 URL: https://issues.apache.org/jira/browse/OAK-3336 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene, query, solr Reporter: Tommaso Teofili Current Lucene and Solr indexes implement quite a no. of features according to their specific APIs, design and implementation. However in the long run, while differences in APIs and implementations will / can of course stay, the difference in design can make it hard to keep those features on par. It'd be therefore nice to make it possible to abstract as much of design and implementation bits as possible in an abstract full text implementation which Lucene and Solr would extend according to their specifics. An example advantage of this is that index time aggregation will be implemented only once and therefore any bugfixes and improvements in that area will be done in the abstract implementation rather than having to do that in two places. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr
[ https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated OAK-3336: - Fix Version/s: 1.4 > Abstract a full text index implementation to be extended by Lucene and Solr > --- > > Key: OAK-3336 > URL: https://issues.apache.org/jira/browse/OAK-3336 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query, solr >Reporter: Tommaso Teofili > Fix For: 1.4 > > > Current Lucene and Solr indexes implement quite a no. of features according > to their specific APIs, design and implementation. However in the long run, > while differences in APIs and implementations will / can of course stay, the > difference in design can make it hard to keep those features on par. > It'd be therefore nice to make it possible to abstract as much of design and > implementation bits as possible in an abstract full text implementation which > Lucene and Solr would extend according to their specifics. > An example advantage of this is that index time aggregation will be > implemented only once and therefore any bugfixes and improvements in that > area will be done in the abstract implementation rather than having to do > that in two places. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3281) Test failures on trunk: SolrIndexQueryTestIT.sql2
[
https://issues.apache.org/jira/browse/OAK-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727130#comment-14727130
]
Thomas Mueller commented on OAK-3281:
-
This is caused by OAK-2634
> Test failures on trunk: SolrIndexQueryTestIT.sql2
> -
>
> Key: OAK-3281
> URL: https://issues.apache.org/jira/browse/OAK-3281
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Labels: ci, jenkins
> Fix For: 1.3.6
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2}}
> fails regularly on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/350/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=integrationTesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.solr.query/SolrIndexQueryTestIT/sql2/
> {noformat}
> java.lang.Exception: Results in
> target/oajopi.solr.query.SolrIndexQueryTestIT_sql2.txt don't match expected
> results in
> file:/x1/jenkins/jenkins-slave/workspace/Apache%20Jackrabbit%20Oak%20matrix/jdk/jdk1.8.0_11/label/Ubuntu/nsfixtures/DOCUMENT_RDB/profile/integrationTesting/oak-core/target/oak-core-1.4-SNAPSHOT-tests.jar!/org/apache/jackrabbit/oak/query/sql2.txt;
> compare the files for details
> at
> org.apache.jackrabbit.oak.query.AbstractQueryTest.test(AbstractQueryTest.java:232)
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2(SolrIndexQueryTestIT.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3281) Test failures on trunk: SolrIndexQueryTestIT.sql2
[
https://issues.apache.org/jira/browse/OAK-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-3281:
Fix Version/s: 1.2.5
1.0.20
> Test failures on trunk: SolrIndexQueryTestIT.sql2
> -
>
> Key: OAK-3281
> URL: https://issues.apache.org/jira/browse/OAK-3281
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Labels: ci, jenkins
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2}}
> fails regularly on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/350/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=integrationTesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.solr.query/SolrIndexQueryTestIT/sql2/
> {noformat}
> java.lang.Exception: Results in
> target/oajopi.solr.query.SolrIndexQueryTestIT_sql2.txt don't match expected
> results in
> file:/x1/jenkins/jenkins-slave/workspace/Apache%20Jackrabbit%20Oak%20matrix/jdk/jdk1.8.0_11/label/Ubuntu/nsfixtures/DOCUMENT_RDB/profile/integrationTesting/oak-core/target/oak-core-1.4-SNAPSHOT-tests.jar!/org/apache/jackrabbit/oak/query/sql2.txt;
> compare the files for details
> at
> org.apache.jackrabbit.oak.query.AbstractQueryTest.test(AbstractQueryTest.java:232)
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2(SolrIndexQueryTestIT.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3333) SplitOperations purges _commitRoot entries too eagerly
[ https://issues.apache.org/jira/browse/OAK-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-. --- Resolution: Fixed Fixed in trunk: http://svn.apache.org/r1700749 > SplitOperations purges _commitRoot entries too eagerly > -- > > Key: OAK- > URL: https://issues.apache.org/jira/browse/OAK- > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.0.12, 1.2, 1.3.5 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > > OAK-2528 introduced purging of _commitRoot entries without associated local > changes on the document. Those _commitRoot entries are created when a child > nodes is added and the _children flag is touched on the parent. > The purge operation is too eager and removes all such entries, which may > result in an undetected hierarchy conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2712) Possible null-dereference when calling ItemImpl#perform
[
https://issues.apache.org/jira/browse/OAK-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-2712:
Affects Version/s: 1.0.19
> Possible null-dereference when calling ItemImpl#perform
> ---
>
> Key: OAK-2712
> URL: https://issues.apache.org/jira/browse/OAK-2712
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.4, 1.0.19
>Reporter: angela
>Assignee: angela
> Labels: technical_debt
> Fix For: 1.3.0, 1.2.5
>
>
> FindBugs complains about usages of ItemImpl#perform that is annotated with
> {{@CheckForNull}} but callers expecting a non-null return value most
> prominently in NodeImpl
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2712) Possible null-dereference when calling ItemImpl#perform
[
https://issues.apache.org/jira/browse/OAK-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-2712:
Fix Version/s: 1.2.5
> Possible null-dereference when calling ItemImpl#perform
> ---
>
> Key: OAK-2712
> URL: https://issues.apache.org/jira/browse/OAK-2712
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.2.4, 1.0.19
>Reporter: angela
>Assignee: angela
> Labels: technical_debt
> Fix For: 1.3.0, 1.2.5
>
>
> FindBugs complains about usages of ItemImpl#perform that is annotated with
> {{@CheckForNull}} but callers expecting a non-null return value most
> prominently in NodeImpl
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3281) Test failures on trunk: SolrIndexQueryTestIT.sql2
[
https://issues.apache.org/jira/browse/OAK-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727136#comment-14727136
]
Thomas Mueller commented on OAK-3281:
-
http://svn.apache.org/r1700755 (trunk, 1.0 branch, 1.2 branch)
> Test failures on trunk: SolrIndexQueryTestIT.sql2
> -
>
> Key: OAK-3281
> URL: https://issues.apache.org/jira/browse/OAK-3281
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Environment:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Labels: ci, jenkins
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2}}
> fails regularly on Jenkins:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/350/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=integrationTesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.solr.query/SolrIndexQueryTestIT/sql2/
> {noformat}
> java.lang.Exception: Results in
> target/oajopi.solr.query.SolrIndexQueryTestIT_sql2.txt don't match expected
> results in
> file:/x1/jenkins/jenkins-slave/workspace/Apache%20Jackrabbit%20Oak%20matrix/jdk/jdk1.8.0_11/label/Ubuntu/nsfixtures/DOCUMENT_RDB/profile/integrationTesting/oak-core/target/oak-core-1.4-SNAPSHOT-tests.jar!/org/apache/jackrabbit/oak/query/sql2.txt;
> compare the files for details
> at
> org.apache.jackrabbit.oak.query.AbstractQueryTest.test(AbstractQueryTest.java:232)
> at
> org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTestIT.sql2(SolrIndexQueryTestIT.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3042) Suspend commit on external conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3042: -- Fix Version/s: 1.3.6 > Suspend commit on external conflict > --- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3337) CIHelper methods related to travis outdated
[
https://issues.apache.org/jira/browse/OAK-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-3337.
---
Resolution: Fixed
Replaced usage of profile related methods with plain {{travis()}} check.
Done in trunk: http://svn.apache.org/r1700775
Merged into 1.2 branch: http://svn.apache.org/r1700776 and 1.0 branch:
http://svn.apache.org/r1700787
> CIHelper methods related to travis outdated
> ---
>
> Key: OAK-3337
> URL: https://issues.apache.org/jira/browse/OAK-3337
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: core
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.0.20, 1.3.6, 1.2.5
>
>
> The travis related methods in CIHelper are outdated. The travis builds do not
> use the PROFILE environment variable anymore.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3156) Lucene suggestions index definition can't be restricted to a specific type of node
[
https://issues.apache.org/jira/browse/OAK-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727266#comment-14727266
]
Vikas Saurabh commented on OAK-3156:
I'm not sure of support for xpath wrt to suggest/spellcheck. But, I think
querying over higher level nodes under a sub-path can be useful. e.g.
{noformat}
SELECT [rep:spellcheck()] FROM [app:Asset] AS s WHERE SPELLCHECK('helo') AND
ISDESCENDANTNODE(s, [/content/subPath1])
{noformat}
to imply looking at suggestions from nodes of type app:Asset or sub-types and
under /content/subPath1. I know, I'm jumping the gun here for a feature which
doesn't exist current -- I just wanted to mention that it might make sense to
work on specific types of nodes under certain paths... I think for all cases
those parameters would be useful only for picking the correct index.
> Lucene suggestions index definition can't be restricted to a specific type of
> node
> --
>
> Key: OAK-3156
> URL: https://issues.apache.org/jira/browse/OAK-3156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Tommaso Teofili
> Attachments: LuceneIndexSuggestionTest.java, OAK-3156-take2.patch,
> OAK-3156.patch
>
>
> While performing a suggestor query like
> {code}
> SELECT [rep:suggest()] as suggestion FROM [nt:unstructured] WHERE
> suggest('foo')
> {code}
> Suggestor does not provide any result. In current implementation,
> [suggestions|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Suggestions]
> in Oak work only for index definitions for {{nt:base}} nodetype.
> So, an index definition like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> works, but if we change nodetype to {{nt:unstructured}} like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> , it won't work.
> The issue is that suggestor implementation essentially is passing a pseudo
> row with path=/.:
> {code:title=LucenePropertyIndex.java}
> private boolean loadDocs() {
> ...
> queue.add(new LuceneResultRow(suggestedWords));
> ...
> {code}
> and
> {code:title=LucenePropertyIndex.java}
> LuceneResultRow(Iterable suggestWords) {
> this.path = "/";
> this.score = 1.0d;
> this.suggestWords = suggestWords;
> }
> {code}
> Due to path being set to "/", {{SelectorImpl}} later filters out the result
> as {{rep:root}} (primary type of "/") isn't a {{nt:unstructured}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3156) Lucene suggestions index definition can't be restricted to a specific type of node
[
https://issues.apache.org/jira/browse/OAK-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727266#comment-14727266
]
Vikas Saurabh edited comment on OAK-3156 at 9/2/15 12:40 PM:
-
I'm not sure of support for xpath wrt to suggest/spellcheck. But, I think
querying over higher level nodes under a sub-path can be useful. e.g.
{noformat}
SELECT [rep:suggest()] FROM [app:Asset] AS s WHERE SUGGEST() AND
ISDESCENDANTNODE(s, [/content/subPath1])
{noformat}
to imply looking at suggestions from nodes of type app:Asset or sub-types and
under /content/subPath1. I know, I'm jumping the gun here for a feature which
doesn't exist current -- I just wanted to mention that it might make sense to
work on specific types of nodes under certain paths... I think for all cases
those parameters would be useful only for picking the correct index.
was (Author: catholicon):
I'm not sure of support for xpath wrt to suggest/spellcheck. But, I think
querying over higher level nodes under a sub-path can be useful. e.g.
{noformat}
SELECT [rep:spellcheck()] FROM [app:Asset] AS s WHERE SPELLCHECK('helo') AND
ISDESCENDANTNODE(s, [/content/subPath1])
{noformat}
to imply looking at suggestions from nodes of type app:Asset or sub-types and
under /content/subPath1. I know, I'm jumping the gun here for a feature which
doesn't exist current -- I just wanted to mention that it might make sense to
work on specific types of nodes under certain paths... I think for all cases
those parameters would be useful only for picking the correct index.
> Lucene suggestions index definition can't be restricted to a specific type of
> node
> --
>
> Key: OAK-3156
> URL: https://issues.apache.org/jira/browse/OAK-3156
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Tommaso Teofili
> Attachments: LuceneIndexSuggestionTest.java, OAK-3156-take2.patch,
> OAK-3156.patch
>
>
> While performing a suggestor query like
> {code}
> SELECT [rep:suggest()] as suggestion FROM [nt:unstructured] WHERE
> suggest('foo')
> {code}
> Suggestor does not provide any result. In current implementation,
> [suggestions|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Suggestions]
> in Oak work only for index definitions for {{nt:base}} nodetype.
> So, an index definition like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> works, but if we change nodetype to {{nt:unstructured}} like:
> {code:xml}
> jcr:primaryType="oak:QueryIndexDefinition"
> async="async"
> compatVersion="{Long}2"
> type="lucene">
>
>
>
> jcr:primaryType="nt:unstructured"
> analyzed="{Boolean}true"
> name="description"
> propertyIndex="{Boolean}true"
> useInSuggest="{Boolean}true"/>
>
>
>
>
> {code}
> , it won't work.
> The issue is that suggestor implementation essentially is passing a pseudo
> row with path=/.:
> {code:title=LucenePropertyIndex.java}
> private boolean loadDocs() {
> ...
> queue.add(new LuceneResultRow(suggestedWords));
> ...
> {code}
> and
> {code:title=LucenePropertyIndex.java}
> LuceneResultRow(Iterable suggestWords) {
> this.path = "/";
> this.score = 1.0d;
> this.suggestWords = suggestWords;
> }
> {code}
> Due to path being set to "/", {{SelectorImpl}} later filters out the result
> as {{rep:root}} (primary type of "/") isn't a {{nt:unstructured}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3339) Logging in and out many sessions leads to high memory consumption
[
https://issues.apache.org/jira/browse/OAK-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3339:
Summary: Logging in and out many sessions leads to high memory consumption
(was: CLONE - Logging in and out many sessions leads to high memory
consumption )
> Logging in and out many sessions leads to high memory consumption
> --
>
> Key: OAK-3339
> URL: https://issues.apache.org/jira/browse/OAK-3339
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Fix For: 1.1.0
>
>
> See http://markmail.org/message/b65g2suyhhbhnefw for the report and
> {{org.apache.jackrabbit.oak.benchmark.LoginLogoutUserTest}} demonstrating the
> issue. Running that benchmark with 128M heap leads to memory pressure and the
> test performing an order of magnitude worse than when running with 1G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3339) CLONE - Logging in and out many sessions leads to high memory consumption
[
https://issues.apache.org/jira/browse/OAK-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727294#comment-14727294
]
Julian Reschke commented on OAK-3339:
-
This needs to be ported to 1.0 in order to make merging other changes less
painful.
> CLONE - Logging in and out many sessions leads to high memory consumption
> --
>
> Key: OAK-3339
> URL: https://issues.apache.org/jira/browse/OAK-3339
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Fix For: 1.1.0
>
>
> See http://markmail.org/message/b65g2suyhhbhnefw for the report and
> {{org.apache.jackrabbit.oak.benchmark.LoginLogoutUserTest}} demonstrating the
> issue. Running that benchmark with 128M heap leads to memory pressure and the
> test performing an order of magnitude worse than when running with 1G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3339) CLONE - Logging in and out many sessions leads to high memory consumption
[
https://issues.apache.org/jira/browse/OAK-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3339:
Affects Version/s: 1.0.19
> CLONE - Logging in and out many sessions leads to high memory consumption
> --
>
> Key: OAK-3339
> URL: https://issues.apache.org/jira/browse/OAK-3339
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Fix For: 1.1.0
>
>
> See http://markmail.org/message/b65g2suyhhbhnefw for the report and
> {{org.apache.jackrabbit.oak.benchmark.LoginLogoutUserTest}} demonstrating the
> issue. Running that benchmark with 128M heap leads to memory pressure and the
> test performing an order of magnitude worse than when running with 1G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727323#comment-14727323 ] Julian Reschke commented on OAK-3042: - This sounds like an improvement that would also be useful in 1.2 and 1.0... > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3042: -- Attachment: commit-graph.png > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > Attachments: commit-graph.png > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3333) SplitOperations purges _commitRoot entries too eagerly
[ https://issues.apache.org/jira/browse/OAK-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-: -- Fix Version/s: 1.2.5 1.0.20 Merged into 1.2 branch: http://svn.apache.org/r1700768 and 1.0 branch: http://svn.apache.org/r1700780 > SplitOperations purges _commitRoot entries too eagerly > -- > > Key: OAK- > URL: https://issues.apache.org/jira/browse/OAK- > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.0.12, 1.2, 1.3.5 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.0.20, 1.3.6, 1.2.5 > > > OAK-2528 introduced purging of _commitRoot entries without associated local > changes on the document. Those _commitRoot entries are created when a child > nodes is added and the _children flag is touched on the parent. > The purge operation is too eager and removes all such entries, which may > result in an undetected hierarchy conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3042: -- Summary: Suspend commit on conflict (was: Suspend commit on external conflict) > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3042) Suspend commit on external conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3042: -- Labels: resilience (was: performance) > Suspend commit on external conflict > --- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3287) DocumentMK revision GC
[ https://issues.apache.org/jira/browse/OAK-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3287: -- Summary: DocumentMK revision GC (was: DocMK revision GC) > DocumentMK revision GC > -- > > Key: OAK-3287 > URL: https://issues.apache.org/jira/browse/OAK-3287 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Reporter: Michael Marth > Fix For: 1.3.7 > > > Collector for various tasks on implementing DocMK revision GC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3036) DocumentRootBuilder: revisit update.limit default
[ https://issues.apache.org/jira/browse/OAK-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3036: --- Component/s: segmentmk > DocumentRootBuilder: revisit update.limit default > - > > Key: OAK-3036 > URL: https://issues.apache.org/jira/browse/OAK-3036 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk, segmentmk >Reporter: Julian Reschke > Labels: performance > Fix For: 1.3.8 > > > update.limit decides whether a commit is persisted using a branch or not. The > default is 1 (and can be overridden using the system property). > A typical call pattern in JCR is to persist batches of ~1024 nodes. These > translate to more than 1 changes (see PackageImportIT), due to JCR > properties, and also indexing commit hooks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-3339) Logging in and out many sessions leads to high memory consumption
[
https://issues.apache.org/jira/browse/OAK-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-3339:
---
Assignee: Julian Reschke (was: Michael Dürig)
> Logging in and out many sessions leads to high memory consumption
> --
>
> Key: OAK-3339
> URL: https://issues.apache.org/jira/browse/OAK-3339
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.0.19
>Reporter: Michael Dürig
>Assignee: Julian Reschke
> Fix For: 1.1.0
>
>
> See http://markmail.org/message/b65g2suyhhbhnefw for the report and
> {{org.apache.jackrabbit.oak.benchmark.LoginLogoutUserTest}} demonstrating the
> issue. Running that benchmark with 128M heap leads to memory pressure and the
> test performing an order of magnitude worse than when running with 1G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3036) DocumentRootBuilder: revisit update.limit default
[ https://issues.apache.org/jira/browse/OAK-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3036: -- Labels: performance (was: resilience) Fix Version/s: (was: 1.3.6) 1.3.8 I rather consider this a performance related improvement. > DocumentRootBuilder: revisit update.limit default > - > > Key: OAK-3036 > URL: https://issues.apache.org/jira/browse/OAK-3036 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Reporter: Julian Reschke > Labels: performance > Fix For: 1.3.8 > > > update.limit decides whether a commit is persisted using a branch or not. The > default is 1 (and can be overridden using the system property). > A typical call pattern in JCR is to persist batches of ~1024 nodes. These > translate to more than 1 changes (see PackageImportIT), due to JCR > properties, and also indexing commit hooks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3339) CLONE - Logging in and out many sessions leads to high memory consumption
Julian Reschke created OAK-3339:
---
Summary: CLONE - Logging in and out many sessions leads to high
memory consumption
Key: OAK-3339
URL: https://issues.apache.org/jira/browse/OAK-3339
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Reporter: Michael Dürig
Assignee: Michael Dürig
Fix For: 1.1.0
See http://markmail.org/message/b65g2suyhhbhnefw for the report and
{{org.apache.jackrabbit.oak.benchmark.LoginLogoutUserTest}} demonstrating the
issue. Running that benchmark with 128M heap leads to memory pressure and the
test performing an order of magnitude worse than when running with 1G.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3042: -- Attachment: OAK-3042.patch Attached patch introduces a ConflictException with a conflict revision indicating the revision of the conflicting commit. This allows the merge to wait for the conflicting commit to finish and become visible and then perform a retry. > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > Attachments: OAK-3042.patch, commit-graph-patched.png, > commit-graph.png > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3042: -- Attachment: commit-graph-patched.png > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > Attachments: OAK-3042.patch, commit-graph-patched.png, > commit-graph.png > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727453#comment-14727453 ] Marcel Reutegger commented on OAK-3042: --- With the patch, the commit rate across sessions is much smoother: !commit-graph-patched.png|width=100%! > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > Attachments: OAK-3042.patch, commit-graph-patched.png, > commit-graph.png > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3042) Suspend commit on conflict
[ https://issues.apache.org/jira/browse/OAK-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727326#comment-14727326 ] Marcel Reutegger edited comment on OAK-3042 at 9/2/15 2:53 PM: --- Turning the data of a test run into a stacked graph shows something like this: !commit-graph.png|width=100%! Every now and then the commit rate drops to zero for a session and sometimes only one session makes progress. was (Author: mreutegg): Turning the data of a test run into a stacked graph shows something like this: !commit-graph.png|with=100%! Every now and then the commit rate drops to zero for a session and sometimes only one session makes progress. > Suspend commit on conflict > -- > > Key: OAK-3042 > URL: https://issues.apache.org/jira/browse/OAK-3042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.3.6 > > Attachments: OAK-3042.patch, commit-graph-patched.png, > commit-graph.png > > > A DocumentNodeStore cluster currently shows a conflict behavior, which > is not intuitive. A modification may fail with a conflict even though > before and after the conflict, the external change is not visible to > the current session. There are two aspects to this issue. > 1) a modification may conflict with a change done on another cluster > node, which is committed but not yet visible on the current cluster node. > 2) even after the InvalidItemStateException caused by the conflict, a > refreshed session may still not see the external change. > The first aspect is a fundamental design decision and cannot be changed > easily. > The second part can be addressed by suspending the commit until the external > conflict becomes visible on the current cluster node. This would at least > avoid the awkward situation where the external change is not visible after > the InvalidItemStateException. > The system would also become more deterministic. A commit currently goes > into a number of retries with exponential back off, but there's no guarantee > the external modification becomes visible within those retries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
