[jira] [Commented] (OAK-9376) Optionally reject queries with huge result sets
[ https://issues.apache.org/jira/browse/OAK-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298051#comment-17298051 ] Vikas Saurabh commented on OAK-9376: [~baedke], I'm not working on oak anymore for some time. So I'd defer to whatever [~thomasm] and [~ngupta] say. > Optionally reject queries with huge result sets > --- > > Key: OAK-9376 > URL: https://issues.apache.org/jira/browse/OAK-9376 > Project: Jackrabbit Oak > Issue Type: Wish > Components: query >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > In cases where processing a result of a query uses a lot of memory and/or > time (e.g. where filtering or ordering of many nodes in memory is required), > an option to set an upper limit to the number of processed nodes and fail the > query if the limit is exceeded would be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-9376) Optionally reject queries with huge result sets
[ https://issues.apache.org/jira/browse/OAK-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298051#comment-17298051 ] Vikas Saurabh edited comment on OAK-9376 at 3/9/21, 12:36 PM: -- [~baedke], I'm not working on oak anymore for quite some time now. So I'd defer to whatever [~thomasm] and [~ngupta] say. was (Author: catholicon): [~baedke], I'm not working on oak anymore for some time. So I'd defer to whatever [~thomasm] and [~ngupta] say. > Optionally reject queries with huge result sets > --- > > Key: OAK-9376 > URL: https://issues.apache.org/jira/browse/OAK-9376 > Project: Jackrabbit Oak > Issue Type: Wish > Components: query >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > In cases where processing a result of a query uses a lot of memory and/or > time (e.g. where filtering or ordering of many nodes in memory is required), > an option to set an upper limit to the number of processed nodes and fail the > query if the limit is exceeded would be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8978) Cache facet results
[ https://issues.apache.org/jira/browse/OAK-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070821#comment-17070821 ] Vikas Saurabh commented on OAK-8978: Iirc, facet results calculation was done once for a result set. It might be a bug over there if it's still attempting to open index for each row. > Cache facet results > --- > > Key: OAK-8978 > URL: https://issues.apache.org/jira/browse/OAK-8978 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > > In OAK-8898, the "AlreadyClosedException" was fixed when reading facet > results. > If the facets are read repeatedly (for each row), then the reader is now > opened and closed each time. This can slow down the application. > It should be possible to cache the facet result in DelayedLuceneFacetProvider -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-7151) Support indexed based excerpts on properties
[
https://issues.apache.org/jira/browse/OAK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014129#comment-17014129
]
Vikas Saurabh commented on OAK-7151:
[~thomasm] iirc, I had kept this one open for adding test; which clearly didn't
happen. I think this change has passed the test of time at least from
regression pov so we should probably resolve it (it has been released long back.
Can you please do a quick sanity check and resolve it?
> Support indexed based excerpts on properties
>
>
> Key: OAK-7151
> URL: https://issues.apache.org/jira/browse/OAK-7151
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.24.0
>
> Attachments: OAK-7151.patch, OAK-7151.xpath-new-syntax.patch,
> OAK-7151.xpath.patch
>
>
> As discovered in OAK-4401 we fallback to {{SimpleExcerptProvider}} when
> requesting excerpts for properties.
> The issue as highlighted in [~teofili]'s comment \[0] is that we at time of
> query we don't have information about which all columns/fields would be
> required for excerpts.
> A possible approach is that the query specified explicitly which columns
> would be required in facets (of course, node level excerpt would still be
> supported). This issue is to track that improvement.
> Note: this is *not* a substitute for OAK-4401 which is about doing saner
> highlighting when {{SimpleExcerptProvider}} comes into play e.g. despite this
> issue excerpt for non-stored fields (properties which aren't configured with
> {{useInExcerpt}} in the index definition}, we'd need to fallback to
> {{SimpleExcerptProvider}}.
> /[~tmueller]
> \[0]:
> https://issues.apache.org/jira/browse/OAK-4401?focusedCommentId=15299857=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15299857
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-7370) order by jcr:score desc doesn't work across union query created by optimizing OR clauses
[
https://issues.apache.org/jira/browse/OAK-7370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh reassigned OAK-7370:
--
Assignee: Thomas Mueller (was: Vikas Saurabh)
[~thomasm], assigning this issue to you. Also, I think we can remove
fixVersion, right?
> order by jcr:score desc doesn't work across union query created by optimizing
> OR clauses
>
>
> Key: OAK-7370
> URL: https://issues.apache.org/jira/browse/OAK-7370
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Vikas Saurabh
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.20.0
>
>
> Merging of sub-queries created due to optimizing OR clauses doesn't work for
> sorting on {{jcr:score}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-6833) LuceneIndex*Test failures
[
https://issues.apache.org/jira/browse/OAK-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-6833.
Fix Version/s: (was: 1.20.0)
Resolution: Cannot Reproduce
[~reschke], I think we haven't seen these failures for a long time. Resolving
this one as not reproducible. Please re-open if that's not correct.
> LuceneIndex*Test failures
> -
>
> Key: OAK-6833
> URL: https://issues.apache.org/jira/browse/OAK-6833
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
>Priority: Major
> Attachments:
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt,
> unit-tests.log, unit-tests.log, unit-tests.log
>
>
> {noformat}
> [ERROR] testLuceneWithRelativeProperty[1: useBlobStore
> (false)](org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest)
> Time elapsed: 0.063 s <<< FAILURE!
> java.lang.AssertionError: expected: but was:
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.testLuceneWithRelativeProperty(LuceneIndexEditorTest.java:341)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8642) Add warn logs while indexing if string property is larger than 100KB.
[ https://issues.apache.org/jira/browse/OAK-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8642: --- Attachment: OAK-8642.patch > Add warn logs while indexing if string property is larger than 100KB. > - > > Key: OAK-8642 > URL: https://issues.apache.org/jira/browse/OAK-8642 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > Attachments: OAK-8642.patch > > > Log a warning if we index a string property whose size is greater than 100KB -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8603) Composite Node Store + Counter Index: allow indexing from scratch / reindex
[
https://issues.apache.org/jira/browse/OAK-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8603.
Fix Version/s: 1.18.0
Resolution: Fixed
Done on trunk at [r1867370|https://svn.apache.org/r1867370] (refactoring) and
[r1867371|https://svn.apache.org/r1867371] (fix).
Thanks [~fabrizio.fort...@gmail.com] for the contribution.
> Composite Node Store + Counter Index: allow indexing from scratch / reindex
> ---
>
> Key: OAK-8603
> URL: https://issues.apache.org/jira/browse/OAK-8603
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, indexing
>Reporter: Thomas Mueller
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: fabriziofortino
> Fix For: 1.18.0
>
> Attachments: OAK-8603.patch, OAK-8603_2.patch, OAK-8603_3_fix.patch,
> OAK-8603_3_refactor.patch
>
>
> When using the composite node store with a read-only portion of the
> repository, the counter index does not allow to index from scratch / reindex.
> Index from scratch is needed in case the async checkpoint is lost. Reindex is
> started by setting the "reindex" flag to true.
> Currently the failure is:
> {noformat}
> 05.09.2019 09:29:21.892 *WARN* [async-index-update-async]
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index
> update is still failing
> java.lang.UnsupportedOperationException: This builder is read-only.
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.unsupported(ReadOnlyBuilder.java:44)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:189)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:34)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leaveNew(NodeCounterEditor.java:162)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leave(NodeCounterEditor.java:114)
>
[jira] [Updated] (OAK-8639) Composite node store tests with document store
[
https://issues.apache.org/jira/browse/OAK-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8639:
---
Description:
CompositeNodeStore tests using document store (h2, document memory) are
currently disabled because the index creation does not work.
[https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/composite/CompositeNodeStoreQueryTestBase.java]
The below assertion fails because the lucene index is not found. This does not
happen with segment and memory stores.
{noformat}
java.lang.AssertionError: java.lang.AssertionError: Expected: a string
containing "/* traverse \"//*\" where ([a].[foo] = 'bar'" but: was "plan:
[nt:base] as [a] /* lucene:luceneTest(/oak:index/luceneTest) foo:bar where
([a].[foo] = 'bar') and (isdescendantnode([a], [/])) */ "Expected :a string
containing "/* traverse \"//*\" where ([a].[foo] = 'bar'"Actual :"plan:
[nt:base] as [a] /* lucene:luceneTest(/oak:index/luceneTest) foo:bar where
([a].[foo] = 'bar') and (isdescendantnode([a], [/])) */ "
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.Assert.assertThat(Assert.java:923)
at
org.apache.jackrabbit.oak.composite.CompositeNodeStoreLuceneIndexTest.removeLuceneIndex(CompositeNodeStoreLuceneIndexTest.java:169)
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:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{noformat}
was:
CompositeNodeStore tests using document store (h2, document memory) are
currently disabled because the index creation does not work.
[https://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/composite/CompositeNodeStoreQueryTestBase.java]
The below assertion fails because the lucene index is not found. This does not
happen with segment and memory stores.
{code:java}
java.lang.AssertionError: java.lang.AssertionError: Expected: a string
containing "/* traverse \"//*\" where ([a].[foo] = 'bar'" but: was "plan:
[nt:base] as [a] /* lucene:luceneTest(/oak:index/luceneTest) foo:bar where
([a].[foo] = 'bar') and (isdescendantnode([a], [/])) */ "Expected :a string
containing "/* traverse \"//*\" where ([a].[foo] = 'bar'"Actual :"plan:
[nt:base] as [a] /* lucene:luceneTest(/oak:index/luceneTest) foo:bar where
([a].[foo] = 'bar') and (isdescendantnode([a], [/])) */ "
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at
[jira] [Updated] (OAK-8603) Composite Node Store + Counter Index: allow indexing from scratch / reindex
[
https://issues.apache.org/jira/browse/OAK-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8603:
---
Attachment: OAK-8603_3_fix.patch
> Composite Node Store + Counter Index: allow indexing from scratch / reindex
> ---
>
> Key: OAK-8603
> URL: https://issues.apache.org/jira/browse/OAK-8603
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, indexing
>Reporter: Thomas Mueller
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: fabriziofortino
> Attachments: OAK-8603.patch, OAK-8603_2.patch, OAK-8603_3_fix.patch,
> OAK-8603_3_refactor.patch
>
>
> When using the composite node store with a read-only portion of the
> repository, the counter index does not allow to index from scratch / reindex.
> Index from scratch is needed in case the async checkpoint is lost. Reindex is
> started by setting the "reindex" flag to true.
> Currently the failure is:
> {noformat}
> 05.09.2019 09:29:21.892 *WARN* [async-index-update-async]
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index
> update is still failing
> java.lang.UnsupportedOperationException: This builder is read-only.
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.unsupported(ReadOnlyBuilder.java:44)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:189)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:34)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leaveNew(NodeCounterEditor.java:162)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leave(NodeCounterEditor.java:114)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:73)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
>
[jira] [Updated] (OAK-8603) Composite Node Store + Counter Index: allow indexing from scratch / reindex
[
https://issues.apache.org/jira/browse/OAK-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8603:
---
Attachment: (was: OAK-8603_3_fix.patch)
> Composite Node Store + Counter Index: allow indexing from scratch / reindex
> ---
>
> Key: OAK-8603
> URL: https://issues.apache.org/jira/browse/OAK-8603
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, indexing
>Reporter: Thomas Mueller
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: fabriziofortino
> Attachments: OAK-8603.patch, OAK-8603_2.patch, OAK-8603_3_fix.patch,
> OAK-8603_3_refactor.patch
>
>
> When using the composite node store with a read-only portion of the
> repository, the counter index does not allow to index from scratch / reindex.
> Index from scratch is needed in case the async checkpoint is lost. Reindex is
> started by setting the "reindex" flag to true.
> Currently the failure is:
> {noformat}
> 05.09.2019 09:29:21.892 *WARN* [async-index-update-async]
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index
> update is still failing
> java.lang.UnsupportedOperationException: This builder is read-only.
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.unsupported(ReadOnlyBuilder.java:44)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:189)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:34)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leaveNew(NodeCounterEditor.java:162)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leave(NodeCounterEditor.java:114)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:73)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
>
[jira] [Updated] (OAK-8603) Composite Node Store + Counter Index: allow indexing from scratch / reindex
[
https://issues.apache.org/jira/browse/OAK-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8603:
---
Attachment: OAK-8603_3_refactor.patch
OAK-8603_3_fix.patch
> Composite Node Store + Counter Index: allow indexing from scratch / reindex
> ---
>
> Key: OAK-8603
> URL: https://issues.apache.org/jira/browse/OAK-8603
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, indexing
>Reporter: Thomas Mueller
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: fabriziofortino
> Attachments: OAK-8603.patch, OAK-8603_2.patch, OAK-8603_3_fix.patch,
> OAK-8603_3_refactor.patch
>
>
> When using the composite node store with a read-only portion of the
> repository, the counter index does not allow to index from scratch / reindex.
> Index from scratch is needed in case the async checkpoint is lost. Reindex is
> started by setting the "reindex" flag to true.
> Currently the failure is:
> {noformat}
> 05.09.2019 09:29:21.892 *WARN* [async-index-update-async]
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index
> update is still failing
> java.lang.UnsupportedOperationException: This builder is read-only.
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.unsupported(ReadOnlyBuilder.java:44)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:189)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:34)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leaveNew(NodeCounterEditor.java:162)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leave(NodeCounterEditor.java:114)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:73)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
>
[jira] [Commented] (OAK-8603) Composite Node Store + Counter Index: allow indexing from scratch / reindex
[
https://issues.apache.org/jira/browse/OAK-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16934460#comment-16934460
]
Vikas Saurabh commented on OAK-8603:
[~fabrizio.fort...@gmail.com], here are few things I'd probably want to change:
* maybe we should split the patch into refactoring and impl+test (I'm ok to
refactor in context of this issue - I just feel that splitting it into 2
commits might be better)
* maybe we can remove {{before}} and {{after}} from {{leaveNew}} method
* I'm not completely sure if making {{TEMPORARY_FOLDER}} as a static class
rule is a good idea - afaict, that would mean that different tests would use
the same temp folder and hence can theoretically interfere with each other
* I think {{reindexCounterTest}} should really reside in {{oak-core}}.
* Kinda on the same lines, why do we need to setup lucene index for testing
counter index?
*
{code:java}
// retrieve counter again (maybe not needed)
c =
s.getRootNode().getNode(INDEX_DEFINITIONS_NAME).getNode("counter");{code}
This is indeed not needed
* In the spirit of refactoring, maybe we should have an {{@After}} method that
can do {{repoV1.cleanup()}}
Here's what I've got [^OAK-8603_3_fix.patch] [^OAK-8603_3_refactor.patch]
(other than having the test in oak-core). Wdyt?
> Composite Node Store + Counter Index: allow indexing from scratch / reindex
> ---
>
> Key: OAK-8603
> URL: https://issues.apache.org/jira/browse/OAK-8603
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, indexing
>Reporter: Thomas Mueller
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: fabriziofortino
> Attachments: OAK-8603.patch, OAK-8603_2.patch, OAK-8603_3_fix.patch,
> OAK-8603_3_refactor.patch
>
>
> When using the composite node store with a read-only portion of the
> repository, the counter index does not allow to index from scratch / reindex.
> Index from scratch is needed in case the async checkpoint is lost. Reindex is
> started by setting the "reindex" flag to true.
> Currently the failure is:
> {noformat}
> 05.09.2019 09:29:21.892 *WARN* [async-index-update-async]
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index
> update is still failing
> java.lang.UnsupportedOperationException: This builder is read-only.
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.unsupported(ReadOnlyBuilder.java:44)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:189)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:34)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
>
[jira] [Assigned] (OAK-8603) Composite Node Store + Counter Index: allow indexing from scratch / reindex
[
https://issues.apache.org/jira/browse/OAK-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh reassigned OAK-8603:
--
Assignee: Vikas Saurabh (was: Thomas Mueller)
> Composite Node Store + Counter Index: allow indexing from scratch / reindex
> ---
>
> Key: OAK-8603
> URL: https://issues.apache.org/jira/browse/OAK-8603
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, indexing
>Reporter: Thomas Mueller
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: fabriziofortino
> Attachments: OAK-8603.patch, OAK-8603_2.patch
>
>
> When using the composite node store with a read-only portion of the
> repository, the counter index does not allow to index from scratch / reindex.
> Index from scratch is needed in case the async checkpoint is lost. Reindex is
> started by setting the "reindex" flag to true.
> Currently the failure is:
> {noformat}
> 05.09.2019 09:29:21.892 *WARN* [async-index-update-async]
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index
> update is still failing
> java.lang.UnsupportedOperationException: This builder is read-only.
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.unsupported(ReadOnlyBuilder.java:44)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:189)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.child(ReadOnlyBuilder.java:34)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.getBuilder(NodeCounterEditor.java:184)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leaveNew(NodeCounterEditor.java:162)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.plugins.index.counter.NodeCounterEditor.leave(NodeCounterEditor.java:114)
> [org.apache.jackrabbit.oak-core:1.16.0.R1866113]
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.leave(CompositeEditor.java:73)
> [org.apache.jackrabbit.oak-store-spi:1.16.0.R1866113]
> at
>
[jira] [Commented] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931472#comment-16931472
]
Vikas Saurabh commented on OAK-8628:
bq. So maybe MemoryChildNodeEntry should enforce the contract in the
constructor???
+1 to this anyway.
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use {{isHiddenPath()}} instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931469#comment-16931469
]
Vikas Saurabh commented on OAK-8628:
[~reschke], while indeed it seems that {{TraversingCursor}} for
{{ALL_CHILDREN}} and {{PARENT}} path restrictions is preparing
{{MemoryNodeState}} with name to be path to node. But, then I think that
{code}
currentPath = PathUtils.concat(parentPath, name);
{code}
should've thrown an {{IllegalArgumentException}}. Could you point me to a test
that showed the stack mentioned in description.
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use {{isHiddenPath()}} instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931214#comment-16931214
]
Vikas Saurabh commented on OAK-8628:
Btw, note that {{isHiddenPath}} returns true if any of the path fragments in a
given path starts with {{:}}. So, all of these would return true /:foo,
/foo/:foo1and /foo/:foo1/foo2.
So, this is not an exact substitute I think.
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use `isHiddenPath()` instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8532) Osgi based test to verify tika setup is working
[ https://issues.apache.org/jira/browse/OAK-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926595#comment-16926595 ] Vikas Saurabh commented on OAK-8532: Backported to 1.10 branch at [r1866744|https://svn.apache.org/r1866744] and to 1.8 branch at [r1866746|https://svn.apache.org/r1866746]. > Osgi based test to verify tika setup is working > --- > > Key: OAK-8532 > URL: https://issues.apache.org/jira/browse/OAK-8532 > Project: Jackrabbit Oak > Issue Type: Test > Components: search >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0, 1.10.5, 1.8.17 > > > Often it's found that we bump tika version while the setups using oak which > are supposed to provide dependencies for tika do not bump dependencies > version. > That situation often leads to hidden errors that get detected very late as by > definition we are expected to *not* fail on a text extraction (at best log a > DEBUG log in \*BinaryTextExtractor. > With current maven tests we don't hit that situation as maven takes care of > pulling in dependencies transitively. We do miss out on having an OSGi based > test which can kind of server 2 purposes: > * notify us when we do bump tika version > * serve as a reference for versions of dependencies that can work -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (OAK-8535) oak-it-osgi fails with encrypted credentials in settings.xml
[ https://issues.apache.org/jira/browse/OAK-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902683#comment-16902683 ] Vikas Saurabh edited comment on OAK-8535 at 9/10/19 12:43 PM: -- Bumped pax-url-aether to 2.6.1 on trunk at [r1864683|https://svn.apache.org/r1864683]. Backported to 1.10 branch at [r1866745|https://svn.apache.org/r1866745] and to 1.8 branch at [r1866747|https://svn.apache.org/r1866747]. was (Author: catholicon): Bumped pax-url-aether to 2.6.1 on trunk at [r1864683|https://svn.apache.org/r1864683]. > oak-it-osgi fails with encrypted credentials in settings.xml > > > Key: OAK-8535 > URL: https://issues.apache.org/jira/browse/OAK-8535 > Project: Jackrabbit Oak > Issue Type: Test > Components: osgi >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.18.0, 1.10.5, 1.8.17 > > > Due to https://ops4j1.jira.com/browse/PAXURL-133 if encrypted credential > contain '/' then the pax exam setup fails. > Bumping pax-url-aether to 2.6.1 seems to work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OAK-8532) Osgi based test to verify tika setup is working
[ https://issues.apache.org/jira/browse/OAK-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8532: --- Fix Version/s: 1.8.17 1.10.5 > Osgi based test to verify tika setup is working > --- > > Key: OAK-8532 > URL: https://issues.apache.org/jira/browse/OAK-8532 > Project: Jackrabbit Oak > Issue Type: Test > Components: search >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0, 1.10.5, 1.8.17 > > > Often it's found that we bump tika version while the setups using oak which > are supposed to provide dependencies for tika do not bump dependencies > version. > That situation often leads to hidden errors that get detected very late as by > definition we are expected to *not* fail on a text extraction (at best log a > DEBUG log in \*BinaryTextExtractor. > With current maven tests we don't hit that situation as maven takes care of > pulling in dependencies transitively. We do miss out on having an OSGi based > test which can kind of server 2 purposes: > * notify us when we do bump tika version > * serve as a reference for versions of dependencies that can work -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OAK-8535) oak-it-osgi fails with encrypted credentials in settings.xml
[ https://issues.apache.org/jira/browse/OAK-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8535: --- Fix Version/s: 1.8.17 1.10.5 > oak-it-osgi fails with encrypted credentials in settings.xml > > > Key: OAK-8535 > URL: https://issues.apache.org/jira/browse/OAK-8535 > Project: Jackrabbit Oak > Issue Type: Test > Components: osgi >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.18.0, 1.10.5, 1.8.17 > > > Due to https://ops4j1.jira.com/browse/PAXURL-133 if encrypted credential > contain '/' then the pax exam setup fails. > Bumping pax-url-aether to 2.6.1 seems to work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (OAK-8597) lc command is unable to construct OakDirectory
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923458#comment-16923458 ] Vikas Saurabh edited comment on OAK-8597 at 9/5/19 1:56 PM: Fixed on trunk at [r1866457|https://svn.apache.org/r1866457]. Backported to 1.0 branch at [r1866458|https://svn.apache.org/r1866458]. was (Author: catholicon): Fixed on trunk at [r1866457|https://svn.apache.org/r1866457]. > lc command is unable to construct OakDirectory > -- > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.10.0, 1.12.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OAK-8597) lc command is unable to construct OakDirectory
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8597: --- Fix Version/s: 1.10.5 > lc command is unable to construct OakDirectory > -- > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.10.0, 1.12.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0, 1.10.5 > > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (OAK-8597) lc command is unable to construct OakDirectory
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-8597. Fix Version/s: 1.18.0 Resolution: Fixed Fixed on trunk at [r1866457|https://svn.apache.org/r1866457]. > lc command is unable to construct OakDirectory > -- > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.10.0, 1.12.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (OAK-8589) NPE in IndexDefintionBuilder with existing property rule without "name" property
[
https://issues.apache.org/jira/browse/OAK-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8589.
Fix Version/s: 1.18.0
Resolution: Fixed
Fixed on trunk at [r1866456|https://svn.apache.org/r1866456].
> NPE in IndexDefintionBuilder with existing property rule without "name"
> property
>
>
> Key: OAK-8589
> URL: https://issues.apache.org/jira/browse/OAK-8589
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Environment: Inde
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.18.0
>
>
> {{IndexDefinitionBuilder#findExisting}} throws NPE when
> {{IndexDefinitionBuilder}} is initialized with an existing index that has a
> property rule without {{name}} property defined.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8597) lc command is unable to construct OakDirectory
[
https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923441#comment-16923441
]
Vikas Saurabh commented on OAK-8597:
The issue is caused by oak-lucene extending from oak-search led to
{{OakDirectory}} requiring {{LuceneIndexDefinition}} while
{{LuceneCommand.groovy}} kept on passing {{IndexDefinition}} instead.
> lc command is unable to construct OakDirectory
> --
>
> Key: OAK-8597
> URL: https://issues.apache.org/jira/browse/OAK-8597
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.10.0, 1.12.0
>Reporter: Jorge Flórez
>Assignee: Vikas Saurabh
>Priority: Major
>
> When extracting index info from a repository stored in MongoDB the following
> exception is thrown
> C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console
> mongodb://localhost:37017/rRepo4
> Apache Jackrabbit Oak 1.12.0
> Repository connected in read-only mode. Use '--read-write' for write
> operations
> Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191)
> Type ':help' or ':h' for help.
> ---
> /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText
> ERROR groovy.lang.GroovyRuntimeException:
> Could not find matching constructor for:
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder,
> org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition,
> java.lang.Boolean)
> at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory
> (LuceneCommand.groovy:132)
> at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall
> (LuceneCommand.groovy:77)
> at java_lang_Runnable$run.call (Unknown Source)
> at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run
> (GroovyConsole.groovy:265)
> at org.apache.jackrabbit.oak.console.GroovyConsole.run
> (GroovyConsole.groovy:74)
> at org.apache.jackrabbit.oak.console.Console.main (Console.java:74)
> at org.apache.jackrabbit.oak.run.ConsoleCommand.execute
> (ConsoleCommand.java:27)
> at org.apache.jackrabbit.oak.run.Main.main (Main.java:49)
> The same exception is thrown if I try to dump the index.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (OAK-8597) lc command is unable to construct OakDirectory
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8597: --- Affects Version/s: (was: 1.12.0) 1.10.0 > lc command is unable to construct OakDirectory > -- > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.10.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OAK-8597) lc command is unable to construct OakDirectory
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8597: --- Affects Version/s: 1.12.0 > lc command is unable to construct OakDirectory > -- > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.10.0, 1.12.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (OAK-8597) lc command is unable to construct OakDirectory
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8597: --- Summary: lc command is unable to construct OakDirectory (was: lc command throws groovy.lang.GroovyRuntimeException) > lc command is unable to construct OakDirectory > -- > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.12.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (OAK-8597) lc command throws groovy.lang.GroovyRuntimeException
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh reassigned OAK-8597: -- Assignee: Vikas Saurabh > lc command throws groovy.lang.GroovyRuntimeException > > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.12.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (OAK-8589) NPE in IndexDefintionBuilder with existing property rule without "name" property
[
https://issues.apache.org/jira/browse/OAK-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921460#comment-16921460
]
Vikas Saurabh edited comment on OAK-8589 at 9/3/19 2:40 PM:
[~tmueller], can you please review:
{noformat}
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
index 037407e26e..72147939cc 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
@@ -312,7 +312,13 @@ public final class IndexDefinitionBuilder {
private Tree findExisting(String name) {
for (Tree tree : getPropsTree().getChildren()){
-if
(name.equals(tree.getProperty(FulltextIndexConstants.PROP_NAME).getValue(Type.STRING))){
+String treeName = tree.getName();
+PropertyState ps =
tree.getProperty(FulltextIndexConstants.PROP_NAME);
+if(ps != null) {
+treeName = ps.getValue(Type.STRING);
+}
+
+if (name.equals(treeName)) {
return tree;
}
}
diff --git
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
index 2402779cbb..1fecbe6c0a 100644
---
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
+++
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
@@ -973,4 +973,20 @@ public class IndexDefinitionBuilderTest {
assertThat(state.getProperty(INDEX_TAGS).getValue(Type.STRINGS),
Matchers.containsInAnyOrder("foo5"));
}
+
+@Test
+public void unnamedPropertyRuleInExistingIndex() {
+// create an initial index with property rule for "foo"
+builder
+.indexRule("nt:base")
+.property("foo")
+// remove "name" property explicitly
+.getBuilderTree().removeProperty("name");
+NodeState initialIndexState = builder.build();
+
+// Use initial index def to add some other property rule - this should
work
+new IndexDefinitionBuilder(initialIndexState.builder())
+.indexRule("nt:base")
+.property("bar");
+}
}
{noformat}
The idea is basically a copy of what {{PropertyDefinition#getName}} is already
doing except that one works one NodeState while other on Tree.
was (Author: catholicon):
[~tmueller], can you please review:
{noformat}
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
index 037407e26e..72147939cc 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
@@ -312,7 +312,13 @@ public final class IndexDefinitionBuilder {
private Tree findExisting(String name) {
for (Tree tree : getPropsTree().getChildren()){
-if
(name.equals(tree.getProperty(FulltextIndexConstants.PROP_NAME).getValue(Type.STRING))){
+String treeName = tree.getName();
+PropertyState ps =
tree.getProperty(FulltextIndexConstants.PROP_NAME);
+if(ps != null) {
+treeName = ps.getValue(Type.STRING);
+}
+
+if (name.equals(treeName)) {
return tree;
}
}
diff --git
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
index 2402779cbb..1fecbe6c0a 100644
---
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
+++
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
@@ -973,4 +973,20 @@ public class IndexDefinitionBuilderTest {
assertThat(state.getProperty(INDEX_TAGS).getValue(Type.STRINGS),
Matchers.containsInAnyOrder("foo5"));
}
+
+@Test
+public void unnamedPropertyRuleInExistingIndex() {
+// create an initial index with property
[jira] [Comment Edited] (OAK-8589) NPE in IndexDefintionBuilder with existing property rule without "name" property
[
https://issues.apache.org/jira/browse/OAK-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921460#comment-16921460
]
Vikas Saurabh edited comment on OAK-8589 at 9/3/19 2:35 PM:
[~tmueller], can you please review:
{noformat}
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
index 037407e26e..72147939cc 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
@@ -312,7 +312,13 @@ public final class IndexDefinitionBuilder {
private Tree findExisting(String name) {
for (Tree tree : getPropsTree().getChildren()){
-if
(name.equals(tree.getProperty(FulltextIndexConstants.PROP_NAME).getValue(Type.STRING))){
+String treeName = tree.getName();
+PropertyState ps =
tree.getProperty(FulltextIndexConstants.PROP_NAME);
+if(ps != null) {
+treeName = ps.getValue(Type.STRING);
+}
+
+if (name.equals(treeName)) {
return tree;
}
}
diff --git
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
index 2402779cbb..1fecbe6c0a 100644
---
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
+++
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
@@ -973,4 +973,20 @@ public class IndexDefinitionBuilderTest {
assertThat(state.getProperty(INDEX_TAGS).getValue(Type.STRINGS),
Matchers.containsInAnyOrder("foo5"));
}
+
+@Test
+public void unnamedPropertyRuleInExistingIndex() {
+// create an initial index with property rule for "foo"
+builder
+.indexRule("nt:base")
+.property("foo")
+// remove "name" property explicitly
+.getBuilderTree().removeProperty("name");
+NodeState initialIndexState = builder.build();
+
+// Use initial index def to add some other property rule - this should
work
+new IndexDefinitionBuilder(initialIndexState.builder())
+.indexRule("nt:base")
+.property("bar");
+}
}
{noformat}
The idea is basically a copy of what {{PropertyDefinition#getName}} is already
doing except that one works one NodeState while other on Tree.
was (Author: catholicon):
[~tmueller], can you please review:
{noformat}
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
index 037407e26e..d6e8162d50 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
@@ -312,13 +312,18 @@ public final class IndexDefinitionBuilder {
private Tree findExisting(String name) {
for (Tree tree : getPropsTree().getChildren()){
-if
(name.equals(tree.getProperty(FulltextIndexConstants.PROP_NAME).getValue(Type.STRING))){
+if (name.equals(getName(tree))) {
return tree;
}
}
return null;
}
+private static String getName(Tree definition){
+PropertyState ps =
definition.getProperty(FulltextIndexConstants.PROP_NAME);
+return ps == null ? definition.getName() :
ps.getValue(Type.STRING);
+}
+
private String createPropNodeName(String name, boolean regex) {
name = regex ? "prop" : getSafePropName(name);
if (name.isEmpty()){
diff --git
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
index 2402779cbb..1fecbe6c0a 100644
---
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
+++
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
@@ -973,4 +973,20 @@ public class IndexDefinitionBuilderTest {
[jira] [Comment Edited] (OAK-8589) NPE in IndexDefintionBuilder with existing property rule without "name" property
[
https://issues.apache.org/jira/browse/OAK-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921460#comment-16921460
]
Vikas Saurabh edited comment on OAK-8589 at 9/3/19 2:29 PM:
[~tmueller], can you please review:
{noformat}
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
index 037407e26e..d6e8162d50 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
@@ -312,13 +312,18 @@ public final class IndexDefinitionBuilder {
private Tree findExisting(String name) {
for (Tree tree : getPropsTree().getChildren()){
-if
(name.equals(tree.getProperty(FulltextIndexConstants.PROP_NAME).getValue(Type.STRING))){
+if (name.equals(getName(tree))) {
return tree;
}
}
return null;
}
+private static String getName(Tree definition){
+PropertyState ps =
definition.getProperty(FulltextIndexConstants.PROP_NAME);
+return ps == null ? definition.getName() :
ps.getValue(Type.STRING);
+}
+
private String createPropNodeName(String name, boolean regex) {
name = regex ? "prop" : getSafePropName(name);
if (name.isEmpty()){
diff --git
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
index 2402779cbb..1fecbe6c0a 100644
---
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
+++
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
@@ -973,4 +973,20 @@ public class IndexDefinitionBuilderTest {
assertThat(state.getProperty(INDEX_TAGS).getValue(Type.STRINGS),
Matchers.containsInAnyOrder("foo5"));
}
+
+@Test
+public void unnamedPropertyRuleInExistingIndex() {
+// create an initial index with property rule for "foo"
+builder
+.indexRule("nt:base")
+.property("foo")
+// remove "name" property explicitly
+.getBuilderTree().removeProperty("name");
+NodeState initialIndexState = builder.build();
+
+// Use initial index def to add some other property rule - this should
work
+new IndexDefinitionBuilder(initialIndexState.builder())
+.indexRule("nt:base")
+.property("bar");
+}
}
{noformat}
The idea is basically a copy of what {{PropertyDefinition#getName}} is already
doing except that one works one NodeState while other on Tree.
was (Author: catholicon):
[~tmueller], can you please review:
{noformat}
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
index 037407e26e..d6e8162d50 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
@@ -312,13 +312,18 @@ public final class IndexDefinitionBuilder {
private Tree findExisting(String name) {
for (Tree tree : getPropsTree().getChildren()){
-if
(name.equals(tree.getProperty(FulltextIndexConstants.PROP_NAME).getValue(Type.STRING))){
+if (name.equals(getName(tree, tree.getName( {
return tree;
}
}
return null;
}
+private static String getName(Tree definition, String defaultName){
+PropertyState ps =
definition.getProperty(FulltextIndexConstants.PROP_NAME);
+return ps == null ? defaultName : ps.getValue(Type.STRING);
+}
+
private String createPropNodeName(String name, boolean regex) {
name = regex ? "prop" : getSafePropName(name);
if (name.isEmpty()){
diff --git
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
index 2402779cbb..1fecbe6c0a 100644
---
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
[jira] [Commented] (OAK-8589) NPE in IndexDefintionBuilder with existing property rule without "name" property
[
https://issues.apache.org/jira/browse/OAK-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921460#comment-16921460
]
Vikas Saurabh commented on OAK-8589:
[~tmueller], can you please review:
{noformat}
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
index 037407e26e..d6e8162d50 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilder.java
@@ -312,13 +312,18 @@ public final class IndexDefinitionBuilder {
private Tree findExisting(String name) {
for (Tree tree : getPropsTree().getChildren()){
-if
(name.equals(tree.getProperty(FulltextIndexConstants.PROP_NAME).getValue(Type.STRING))){
+if (name.equals(getName(tree, tree.getName( {
return tree;
}
}
return null;
}
+private static String getName(Tree definition, String defaultName){
+PropertyState ps =
definition.getProperty(FulltextIndexConstants.PROP_NAME);
+return ps == null ? defaultName : ps.getValue(Type.STRING);
+}
+
private String createPropNodeName(String name, boolean regex) {
name = regex ? "prop" : getSafePropName(name);
if (name.isEmpty()){
diff --git
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
index 2402779cbb..1fecbe6c0a 100644
---
a/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
+++
b/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/util/IndexDefinitionBuilderTest.java
@@ -973,4 +973,20 @@ public class IndexDefinitionBuilderTest {
assertThat(state.getProperty(INDEX_TAGS).getValue(Type.STRINGS),
Matchers.containsInAnyOrder("foo5"));
}
+
+@Test
+public void unnamedPropertyRuleInExistingIndex() {
+// create an initial index with property rule for "foo"
+builder
+.indexRule("nt:base")
+.property("foo")
+// remove "name" property explicitly
+.getBuilderTree().removeProperty("name");
+NodeState initialIndexState = builder.build();
+
+// Use initial index def to add some other property rule - this should
work
+new IndexDefinitionBuilder(initialIndexState.builder())
+.indexRule("nt:base")
+.property("bar");
+}
}
{noformat}
The idea is basically a copy of what {{PropertyDefinition#getName}} is already
doing except that one works one NodeState while other on Tree.
> NPE in IndexDefintionBuilder with existing property rule without "name"
> property
>
>
> Key: OAK-8589
> URL: https://issues.apache.org/jira/browse/OAK-8589
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Environment: Inde
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>
> {{IndexDefinitionBuilder#findExisting}} throws NPE when
> {{IndexDefinitionBuilder}} is initialized with an existing index that has a
> property rule without {{name}} property defined.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (OAK-8589) NPE in IndexDefintionBuilder with existing property rule without "name" property
Vikas Saurabh created OAK-8589:
--
Summary: NPE in IndexDefintionBuilder with existing property rule
without "name" property
Key: OAK-8589
URL: https://issues.apache.org/jira/browse/OAK-8589
Project: Jackrabbit Oak
Issue Type: Improvement
Environment: Inde
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
{{IndexDefinitionBuilder#findExisting}} throws NPE when
{{IndexDefinitionBuilder}} is initialized with an existing index that has a
property rule without {{name}} property defined.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8579) Composite Node Store: Allow creating an index in the read-only repo first
[
https://issues.apache.org/jira/browse/OAK-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917572#comment-16917572
]
Vikas Saurabh commented on OAK-8579:
[~tmueller], I was thinking about this issue after we discussed "fix validator
approach". I wonder if another way could (should??) be for diff to not report
"magically appearing node to not be reported in {{childNodeAdded}}". I do see
that this is more hacky - but what I'm really trying to evaluate "should this
new type of node incarnation be treated differently than simple child node
addition". wdyt?
> Composite Node Store: Allow creating an index in the read-only repo first
> -
>
> Key: OAK-8579
> URL: https://issues.apache.org/jira/browse/OAK-8579
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: composite, core, indexing, lucene
>Reporter: Thomas Mueller
>Priority: Major
>
> Currently, it is not allowed to first create a new index in the read-only
> repository, and then in the read-write repository. Trying to do so will fail
> with "OakConstraint0001: /oak:index/.../:oak:mount-readOnlyV1-index-data[[]]:
> The primary type null does not exist"
> See OAK-7917: oak-lucene/src/test/java/org/apache/jackrabbit/oak/composite -
> CompositeNodeStoreLuceneIndexTest.java
> tryAddIndexInReadWriteWithIndexExistinginReadOnly line 112.
> It would be better to allow this use case, to reduce the possibility of
> problems.
> We should specially test with lucene indexes, but also with property indexes.
> (If that's more complicated, we can concentrate on the lucene case first.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8517) javadoc:aggregate build fails
[
https://issues.apache.org/jira/browse/OAK-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913449#comment-16913449
]
Vikas Saurabh commented on OAK-8517:
I'd be ok for removal from reactor temporarily. But sooner or later this would
have to investigated and fixed correctly.
> javadoc:aggregate build fails
> -
>
> Key: OAK-8517
> URL: https://issues.apache.org/jira/browse/OAK-8517
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: doc
>Reporter: Julian Reschke
>Priority: Major
>
> {{mvn site -Pdoc,javadoc}} fails with:
> {noformat}
> [ERROR]
> /mnt/c/projects/apache/oak/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/JackrabbitNode.java:40:
> error: cannot find symbol
> [ERROR] * @param mixinNames
> [ERROR] ^
> [ERROR] symbol: variable LUCENE_47
> [ERROR] location: class Version
> [ERROR]
> /mnt/c/projects/apache/oak/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/OakCodec.java:41:
> error: reference not found
> [ERROR] * It simply mimics {@link Lucene46Codec} but
> [ERROR]^
> [ERROR]
> [ERROR] Command line was: /home/jre/jdk1.8.0_221/jre/../bin/javadoc @options
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/mnt/c/projects/apache/oak/trunk/oak-doc/target/site/apidocs' dir.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (OAK-8554) IndexCopier#waitForCopyCompletion doesn't reset interrupted flag after catching InterruptedException
[
https://issues.apache.org/jira/browse/OAK-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8554.
Resolution: Fixed
Fix Version/s: 1.18.0
Fixed on trunk at [r1865407|https://svn.apache.org/r1865407].
> IndexCopier#waitForCopyCompletion doesn't reset interrupted flag after
> catching InterruptedException
>
>
> Key: OAK-8554
> URL: https://issues.apache.org/jira/browse/OAK-8554
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.18.0
>
>
> As noted by [~frm] at https://twitter.com/frm1025/status/1161705351382798336
> {{IndexCopier#waitForCopyCompletion}} should reset {{interrupt}} status after
> catching {{InterruptedException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (OAK-8543) Javadoc of IndexCopier#waitForCopyCompletion refers to boolean return
[
https://issues.apache.org/jira/browse/OAK-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8543.
Resolution: Fixed
Fix Version/s: 1.18.0
Fixed on trunk at [r1865406|https://svn.apache.org/r1865406].
> Javadoc of IndexCopier#waitForCopyCompletion refers to boolean return
> -
>
> Key: OAK-8543
> URL: https://issues.apache.org/jira/browse/OAK-8543
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.18.0
>
>
> As noted by [~frm] at https://twitter.com/frm1025/status/1161640994787536896,
> javadoc of {{IndexCopier#waitForCopyCompletion}} shouldn't talk about false
> return when the method returns void.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (OAK-8554) IndexCopier#waitForCopyCompletion doesn't reset interrupted flag after catching InterruptedException
Vikas Saurabh created OAK-8554:
--
Summary: IndexCopier#waitForCopyCompletion doesn't reset
interrupted flag after catching InterruptedException
Key: OAK-8554
URL: https://issues.apache.org/jira/browse/OAK-8554
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
As noted by [~frm] at https://twitter.com/frm1025/status/1161705351382798336
{{IndexCopier#waitForCopyCompletion}} should reset {{interrupt}} status after
catching {{InterruptedException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (OAK-8543) Javadoc of IndexCopier#waitForCopyCompletion refers to boolean return
Vikas Saurabh created OAK-8543:
--
Summary: Javadoc of IndexCopier#waitForCopyCompletion refers to
boolean return
Key: OAK-8543
URL: https://issues.apache.org/jira/browse/OAK-8543
Project: Jackrabbit Oak
Issue Type: Documentation
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
As noted by [~frm] at https://twitter.com/frm1025/status/1161640994787536896,
javadoc of {{IndexCopier#waitForCopyCompletion}} shouldn't talk about false
return when the method returns void.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (OAK-8542) Test failure: ConcurrentCopyOnReadDirectoryTest.concurrentPrefetchWithTimeout
[
https://issues.apache.org/jira/browse/OAK-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh reassigned OAK-8542:
--
Assignee: Vikas Saurabh
> Test failure: ConcurrentCopyOnReadDirectoryTest.concurrentPrefetchWithTimeout
> -
>
> Key: OAK-8542
> URL: https://issues.apache.org/jira/browse/OAK-8542
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, lucene
>Reporter: Hudson
>Assignee: Vikas Saurabh
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #2318 has failed.
> First failed run: [Jackrabbit Oak
> #2318|https://builds.apache.org/job/Jackrabbit%20Oak/2318/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2318/console]
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.ConcurrentCopyOnReadDirectoryTest.concurrentPrefetchWithTimeout(ConcurrentCopyOnReadDirectoryTest.java:154)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (OAK-8542) Test failure: ConcurrentCopyOnReadDirectoryTest.concurrentPrefetchWithTimeout
[
https://issues.apache.org/jira/browse/OAK-8542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8542.
Resolution: Fixed
Fix Version/s: 1.18.0
Thanks for looking into it [~mreutegg]. Fixed incorrectly initialized list that
was failing the test at [r1865136|https://svn.apache.org/r1865136].
> Test failure: ConcurrentCopyOnReadDirectoryTest.concurrentPrefetchWithTimeout
> -
>
> Key: OAK-8542
> URL: https://issues.apache.org/jira/browse/OAK-8542
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, lucene
>Reporter: Hudson
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.18.0
>
>
> No description is provided
> The build Jackrabbit Oak #2318 has failed.
> First failed run: [Jackrabbit Oak
> #2318|https://builds.apache.org/job/Jackrabbit%20Oak/2318/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2318/console]
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.ConcurrentCopyOnReadDirectoryTest.concurrentPrefetchWithTimeout(ConcurrentCopyOnReadDirectoryTest.java:154)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (OAK-8535) oak-it-osgi fails with encrypted credentials in settings.xml
[ https://issues.apache.org/jira/browse/OAK-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-8535. Resolution: Fixed Fix Version/s: 1.18.0 Bumped pax-url-aether to 2.6.1 on trunk at [r1864683|https://svn.apache.org/r1864683]. > oak-it-osgi fails with encrypted credentials in settings.xml > > > Key: OAK-8535 > URL: https://issues.apache.org/jira/browse/OAK-8535 > Project: Jackrabbit Oak > Issue Type: Test > Components: osgi >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.18.0 > > > Due to https://ops4j1.jira.com/browse/PAXURL-133 if encrypted credential > contain '/' then the pax exam setup fails. > Bumping pax-url-aether to 2.6.1 seems to work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (OAK-8535) oak-it-osgi fails with encrypted credentials in settings.xml
Vikas Saurabh created OAK-8535: -- Summary: oak-it-osgi fails with encrypted credentials in settings.xml Key: OAK-8535 URL: https://issues.apache.org/jira/browse/OAK-8535 Project: Jackrabbit Oak Issue Type: Test Components: osgi Reporter: Vikas Saurabh Assignee: Vikas Saurabh Due to https://ops4j1.jira.com/browse/PAXURL-133 if encrypted credential contain '/' then the pax exam setup fails. Bumping pax-url-aether to 2.6.1 seems to work. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (OAK-8532) Osgi based test to verify tika setup is working
[ https://issues.apache.org/jira/browse/OAK-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902591#comment-16902591 ] Vikas Saurabh edited comment on OAK-8532 at 8/8/19 4:38 AM: Additional resources broke build due to missing licenses (OAK-8533). Fixed that at [r1864674|https://svn.apache.org/r1864674] and [r1864681|https://svn.apache.org/r1864681]. was (Author: catholicon): Additional resources broke build due to missing licenses (OAK-8533). Fixed that at [r1864674|https://svn.apache.org/r1864674]. > Osgi based test to verify tika setup is working > --- > > Key: OAK-8532 > URL: https://issues.apache.org/jira/browse/OAK-8532 > Project: Jackrabbit Oak > Issue Type: Test > Components: search >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > Often it's found that we bump tika version while the setups using oak which > are supposed to provide dependencies for tika do not bump dependencies > version. > That situation often leads to hidden errors that get detected very late as by > definition we are expected to *not* fail on a text extraction (at best log a > DEBUG log in \*BinaryTextExtractor. > With current maven tests we don't hit that situation as maven takes care of > pulling in dependencies transitively. We do miss out on having an OSGi based > test which can kind of server 2 purposes: > * notify us when we do bump tika version > * server as a reference for versions of dependecies that can work -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8532) Osgi based test to verify tika setup is working
[ https://issues.apache.org/jira/browse/OAK-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8532: --- Description: Often it's found that we bump tika version while the setups using oak which are supposed to provide dependencies for tika do not bump dependencies version. That situation often leads to hidden errors that get detected very late as by definition we are expected to *not* fail on a text extraction (at best log a DEBUG log in \*BinaryTextExtractor. With current maven tests we don't hit that situation as maven takes care of pulling in dependencies transitively. We do miss out on having an OSGi based test which can kind of server 2 purposes: * notify us when we do bump tika version * serve as a reference for versions of dependencies that can work was: Often it's found that we bump tika version while the setups using oak which are supposed to provide dependencies for tika do not bump dependencies version. That situation often leads to hidden errors that get detected very late as by definition we are expected to *not* fail on a text extraction (at best log a DEBUG log in \*BinaryTextExtractor. With current maven tests we don't hit that situation as maven takes care of pulling in dependencies transitively. We do miss out on having an OSGi based test which can kind of server 2 purposes: * notify us when we do bump tika version * server as a reference for versions of dependecies that can work > Osgi based test to verify tika setup is working > --- > > Key: OAK-8532 > URL: https://issues.apache.org/jira/browse/OAK-8532 > Project: Jackrabbit Oak > Issue Type: Test > Components: search >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > Often it's found that we bump tika version while the setups using oak which > are supposed to provide dependencies for tika do not bump dependencies > version. > That situation often leads to hidden errors that get detected very late as by > definition we are expected to *not* fail on a text extraction (at best log a > DEBUG log in \*BinaryTextExtractor. > With current maven tests we don't hit that situation as maven takes care of > pulling in dependencies transitively. We do miss out on having an OSGi based > test which can kind of server 2 purposes: > * notify us when we do bump tika version > * serve as a reference for versions of dependencies that can work -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8533) Rat plugin failure in oak-it-osgi
[ https://issues.apache.org/jira/browse/OAK-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902672#comment-16902672 ] Vikas Saurabh commented on OAK-8533: Build filed again due to rat. For some reason my local run didn't inspect 'docx' resource but apparently it should be mentioned. Added test.doc and test.docx to be ignored by rat plugin at [r1864681|https://svn.apache.org/r1864681]. > Rat plugin failure in oak-it-osgi > - > > Key: OAK-8533 > URL: https://issues.apache.org/jira/browse/OAK-8533 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > The build Jackrabbit Oak #2313 has failed. > First failed run: [Jackrabbit Oak > #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] > Also, failed with > The build Jackrabbit Oak #2314 has failed. > First failed run: [Jackrabbit Oak > #2314|https://builds.apache.org/job/Jackrabbit%20Oak/2314/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2314/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (OAK-8534) Build Jackrabbit Oak #2314 failed
[ https://issues.apache.org/jira/browse/OAK-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-8534. Resolution: Duplicate > Build Jackrabbit Oak #2314 failed > - > > Key: OAK-8534 > URL: https://issues.apache.org/jira/browse/OAK-8534 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2314 has failed. > First failed run: [Jackrabbit Oak > #2314|https://builds.apache.org/job/Jackrabbit%20Oak/2314/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2314/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8533) Rat plugin failure in oak-it-osgi
[ https://issues.apache.org/jira/browse/OAK-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8533: --- Description: The build Jackrabbit Oak #2313 has failed. First failed run: [Jackrabbit Oak #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] Also, failed with The build Jackrabbit Oak #2314 has failed. First failed run: [Jackrabbit Oak #2314|https://builds.apache.org/job/Jackrabbit%20Oak/2314/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2314/console] was: The build Jackrabbit Oak #2313 has failed. First failed run: [Jackrabbit Oak #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] > Rat plugin failure in oak-it-osgi > - > > Key: OAK-8533 > URL: https://issues.apache.org/jira/browse/OAK-8533 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > The build Jackrabbit Oak #2313 has failed. > First failed run: [Jackrabbit Oak > #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] > Also, failed with > The build Jackrabbit Oak #2314 has failed. > First failed run: [Jackrabbit Oak > #2314|https://builds.apache.org/job/Jackrabbit%20Oak/2314/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2314/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8532) Osgi based test to verify tika setup is working
[ https://issues.apache.org/jira/browse/OAK-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902591#comment-16902591 ] Vikas Saurabh commented on OAK-8532: Additional resources broke build due to missing licenses (OAK-8533). Fixed that at [r1864674|https://svn.apache.org/r1864674]. > Osgi based test to verify tika setup is working > --- > > Key: OAK-8532 > URL: https://issues.apache.org/jira/browse/OAK-8532 > Project: Jackrabbit Oak > Issue Type: Test > Components: search >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > Often it's found that we bump tika version while the setups using oak which > are supposed to provide dependencies for tika do not bump dependencies > version. > That situation often leads to hidden errors that get detected very late as by > definition we are expected to *not* fail on a text extraction (at best log a > DEBUG log in \*BinaryTextExtractor. > With current maven tests we don't hit that situation as maven takes care of > pulling in dependencies transitively. We do miss out on having an OSGi based > test which can kind of server 2 purposes: > * notify us when we do bump tika version > * server as a reference for versions of dependecies that can work -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (OAK-8533) Rat plugin failure in oak-it-osgi
[ https://issues.apache.org/jira/browse/OAK-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-8533. Resolution: Fixed Fix Version/s: 1.18.0 Fixed at [r1864674|https://svn.apache.org/r1864674]. > Rat plugin failure in oak-it-osgi > - > > Key: OAK-8533 > URL: https://issues.apache.org/jira/browse/OAK-8533 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > The build Jackrabbit Oak #2313 has failed. > First failed run: [Jackrabbit Oak > #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8533) Rat plugin failure in oak-it-osgi
[ https://issues.apache.org/jira/browse/OAK-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902585#comment-16902585 ] Vikas Saurabh commented on OAK-8533: caused by [r1864667|https://svn.apache.org/r1864667]. > Rat plugin failure in oak-it-osgi > - > > Key: OAK-8533 > URL: https://issues.apache.org/jira/browse/OAK-8533 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Vikas Saurabh >Priority: Major > > The build Jackrabbit Oak #2313 has failed. > First failed run: [Jackrabbit Oak > #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8533) Rat plugin failure in oak-it-osgi
[ https://issues.apache.org/jira/browse/OAK-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8533: --- Summary: Rat plugin failure in oak-it-osgi (was: Build Jackrabbit Oak #2313 failed) > Rat plugin failure in oak-it-osgi > - > > Key: OAK-8533 > URL: https://issues.apache.org/jira/browse/OAK-8533 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Vikas Saurabh >Priority: Major > > No description is provided > The build Jackrabbit Oak #2313 has failed. > First failed run: [Jackrabbit Oak > #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8533) Rat plugin failure in oak-it-osgi
[ https://issues.apache.org/jira/browse/OAK-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8533: --- Description: The build Jackrabbit Oak #2313 has failed. First failed run: [Jackrabbit Oak #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] was: No description is provided The build Jackrabbit Oak #2313 has failed. First failed run: [Jackrabbit Oak #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] > Rat plugin failure in oak-it-osgi > - > > Key: OAK-8533 > URL: https://issues.apache.org/jira/browse/OAK-8533 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Vikas Saurabh >Priority: Major > > The build Jackrabbit Oak #2313 has failed. > First failed run: [Jackrabbit Oak > #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (OAK-8533) Build Jackrabbit Oak #2313 failed
[ https://issues.apache.org/jira/browse/OAK-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh reassigned OAK-8533: -- Assignee: Vikas Saurabh > Build Jackrabbit Oak #2313 failed > - > > Key: OAK-8533 > URL: https://issues.apache.org/jira/browse/OAK-8533 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Vikas Saurabh >Priority: Major > > No description is provided > The build Jackrabbit Oak #2313 has failed. > First failed run: [Jackrabbit Oak > #2313|https://builds.apache.org/job/Jackrabbit%20Oak/2313/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2313/console] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (OAK-8532) Osgi based test to verify tika setup is working
[ https://issues.apache.org/jira/browse/OAK-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-8532. Resolution: Fixed Fix Version/s: 1.18.0 Added a test on trunk at [r1864667|https://svn.apache.org/r1864667]. > Osgi based test to verify tika setup is working > --- > > Key: OAK-8532 > URL: https://issues.apache.org/jira/browse/OAK-8532 > Project: Jackrabbit Oak > Issue Type: Test > Components: search >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0 > > > Often it's found that we bump tika version while the setups using oak which > are supposed to provide dependencies for tika do not bump dependencies > version. > That situation often leads to hidden errors that get detected very late as by > definition we are expected to *not* fail on a text extraction (at best log a > DEBUG log in \*BinaryTextExtractor. > With current maven tests we don't hit that situation as maven takes care of > pulling in dependencies transitively. We do miss out on having an OSGi based > test which can kind of server 2 purposes: > * notify us when we do bump tika version > * server as a reference for versions of dependecies that can work -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (OAK-8532) Osgi based test to verify tika setup is working
Vikas Saurabh created OAK-8532: -- Summary: Osgi based test to verify tika setup is working Key: OAK-8532 URL: https://issues.apache.org/jira/browse/OAK-8532 Project: Jackrabbit Oak Issue Type: Test Components: search Reporter: Vikas Saurabh Assignee: Vikas Saurabh Often it's found that we bump tika version while the setups using oak which are supposed to provide dependencies for tika do not bump dependencies version. That situation often leads to hidden errors that get detected very late as by definition we are expected to *not* fail on a text extraction (at best log a DEBUG log in \*BinaryTextExtractor. With current maven tests we don't hit that situation as maven takes care of pulling in dependencies transitively. We do miss out on having an OSGi based test which can kind of server 2 purposes: * notify us when we do bump tika version * server as a reference for versions of dependecies that can work -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-7251) BinaryTextExtractor should not ignore parse exception - they should at least be logged at DEBUG in all cases
[
https://issues.apache.org/jira/browse/OAK-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7251:
---
Fix Version/s: 1.8.16
> BinaryTextExtractor should not ignore parse exception - they should at least
> be logged at DEBUG in all cases
>
>
> Key: OAK-7251
> URL: https://issues.apache.org/jira/browse/OAK-7251
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.9.0, 1.10.0, 1.8.16
>
>
> BinaryTextExtractor ignores missing library error like:
> {noformat}
> } catch (LinkageError e) {
> // Capture and ignore errors caused by extraction libraries
> // not being present. This is equivalent to disabling
> // selected media types in configuration, so we can simply
> // ignore these errors.
> {noformat}
> or
> {noformat}
> // Capture and report any other full text extraction problems.
> // The special STOP exception is used for normal termination.
> if (!handler.isWriteLimitReached(t)) {
> {noformat}
> We should at not skip these errors - some information should at least be
> available at DEBUG.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-7251) BinaryTextExtractor should not ignore parse exception - they should at least be logged at DEBUG in all cases
[
https://issues.apache.org/jira/browse/OAK-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900811#comment-16900811
]
Vikas Saurabh commented on OAK-7251:
Backported to 1.8 branch at [r1864480|https://svn.apache.org/r1864480].
> BinaryTextExtractor should not ignore parse exception - they should at least
> be logged at DEBUG in all cases
>
>
> Key: OAK-7251
> URL: https://issues.apache.org/jira/browse/OAK-7251
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.9.0, 1.10.0
>
>
> BinaryTextExtractor ignores missing library error like:
> {noformat}
> } catch (LinkageError e) {
> // Capture and ignore errors caused by extraction libraries
> // not being present. This is equivalent to disabling
> // selected media types in configuration, so we can simply
> // ignore these errors.
> {noformat}
> or
> {noformat}
> // Capture and report any other full text extraction problems.
> // The special STOP exception is used for normal termination.
> if (!handler.isWriteLimitReached(t)) {
> {noformat}
> We should at not skip these errors - some information should at least be
> available at DEBUG.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8526:
---
Labels: (was: candidate_oak_1_8)
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.18.0, 1.10.4, 1.8.16
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899549#comment-16899549
]
Vikas Saurabh edited comment on OAK-8526 at 8/4/19 6:11 AM:
Fixed on trunk at [r1864349|https://svn.apache.org/r1864349],
[r1864353|https://svn.apache.org/r1864353].
Backported to 1.10 branch at [r1864352|https://svn.apache.org/r1864352],
[r1864354|https://svn.apache.org/r1864354] and to 1.8 at
[r1864358|https://svn.apache.org/r1864358].
was (Author: catholicon):
Fixed on trunk at [r1864349|https://svn.apache.org/r1864349],
[r1864353|https://svn.apache.org/r1864353].
Backported to 1.10 branch at [r1864352|https://svn.apache.org/r1864352],
[r1864354|https://svn.apache.org/r1864354].
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_8
> Fix For: 1.18.0, 1.10.4
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8526:
---
Fix Version/s: 1.8.16
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_8
> Fix For: 1.18.0, 1.10.4, 1.8.16
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition
[
https://issues.apache.org/jira/browse/OAK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8114:
---
Fix Version/s: 1.8.16
> IndexDefinitionBuilder should be smarter when to reindex while updating a
> definition
>
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: indexingPatch, nitin
> Fix For: 1.12.0, 1.10.4, 1.8.16
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There
> are quite a few properties which only affect querying or cost-estimation and
> don't imply a change in indexed data. For such cases, simply setting
> {{refresh=true}} should suffice.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition
[
https://issues.apache.org/jira/browse/OAK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899555#comment-16899555
]
Vikas Saurabh edited comment on OAK-8114 at 8/4/19 6:03 AM:
Backported to 1.10 branch at [r1864351|https://svn.apache.org/r1864351] and to
1.8 at [r1864357|https://svn.apache.org/r1864357].
was (Author: catholicon):
Backported to 1.10 branch at [r1864351|https://svn.apache.org/r1864351].
> IndexDefinitionBuilder should be smarter when to reindex while updating a
> definition
>
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: indexingPatch, nitin
> Fix For: 1.12.0, 1.10.4, 1.8.16
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There
> are quite a few properties which only affect querying or cost-estimation and
> don't imply a change in indexed data. For such cases, simply setting
> {{refresh=true}} should suffice.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition
[
https://issues.apache.org/jira/browse/OAK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8114:
---
Labels: indexingPatch nitin (was: candidate_oak_1_8 indexingPatch nitin)
> IndexDefinitionBuilder should be smarter when to reindex while updating a
> definition
>
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: indexingPatch, nitin
> Fix For: 1.12.0, 1.10.4
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There
> are quite a few properties which only affect querying or cost-estimation and
> don't imply a change in indexed data. For such cases, simply setting
> {{refresh=true}} should suffice.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (OAK-8041) IndexDefinitionBuilder should support facets and boost for property definitions
[ https://issues.apache.org/jira/browse/OAK-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766035#comment-16766035 ] Vikas Saurabh edited comment on OAK-8041 at 8/4/19 5:57 AM: Done on trunk at [r1853435|https://svn.apache.org/r1853435]. Backported to 1.10 at [r1853440|https://svn.apache.org/r1853440] and to 1.8 at [r1864356|https://svn.apache.org/r1864356]. was (Author: catholicon): Done on trunk at [r1853435|https://svn.apache.org/r1853435]. Backported to 1.10 at [r1853440|https://svn.apache.org/r1853440]. > IndexDefinitionBuilder should support facets and boost for property > definitions > --- > > Key: OAK-8041 > URL: https://issues.apache.org/jira/browse/OAK-8041 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.12.0, 1.10.1 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8041) IndexDefinitionBuilder should support facets and boost for property definitions
[ https://issues.apache.org/jira/browse/OAK-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-8041: --- Fix Version/s: 1.8.16 > IndexDefinitionBuilder should support facets and boost for property > definitions > --- > > Key: OAK-8041 > URL: https://issues.apache.org/jira/browse/OAK-8041 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.12.0, 1.10.1, 1.8.16 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition
[
https://issues.apache.org/jira/browse/OAK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8114:
---
Labels: candidate_oak_1_8 indexingPatch nitin (was: candidate_oak_1_6
candidate_oak_1_8 indexingPatch nitin)
> IndexDefinitionBuilder should be smarter when to reindex while updating a
> definition
>
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_8, indexingPatch, nitin
> Fix For: 1.12.0, 1.10.4
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There
> are quite a few properties which only affect querying or cost-estimation and
> don't imply a change in indexed data. For such cases, simply setting
> {{refresh=true}} should suffice.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899549#comment-16899549
]
Vikas Saurabh edited comment on OAK-8526 at 8/4/19 4:54 AM:
Fixed on trunk at [r1864349|https://svn.apache.org/r1864349],
[r1864353|https://svn.apache.org/r1864353].
Backported to 1.10 branch at [r1864352|https://svn.apache.org/r1864352],
[r1864354|https://svn.apache.org/r1864354].
was (Author: catholicon):
Fixed on trunk at [r1864349|https://svn.apache.org/r1864349].
Backported to 1.10 branch at [r1864352|https://svn.apache.org/r1864352].
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_8
> Fix For: 1.18.0, 1.10.4
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition
[
https://issues.apache.org/jira/browse/OAK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8114:
---
Fix Version/s: 1.10.4
> IndexDefinitionBuilder should be smarter when to reindex while updating a
> definition
>
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_6, candidate_oak_1_8, indexingPatch,
> nitin
> Fix For: 1.12.0, 1.10.4
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There
> are quite a few properties which only affect querying or cost-estimation and
> don't imply a change in indexed data. For such cases, simply setting
> {{refresh=true}} should suffice.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8526:
---
Fix Version/s: 1.10.4
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_8
> Fix For: 1.18.0, 1.10.4
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition
[
https://issues.apache.org/jira/browse/OAK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8114:
---
Labels: candidate_oak_1_6 candidate_oak_1_8 indexingPatch nitin (was:
candidate_oak_1_10 candidate_oak_1_6 candidate_oak_1_8 indexingPatch nitin)
> IndexDefinitionBuilder should be smarter when to reindex while updating a
> definition
>
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_6, candidate_oak_1_8, indexingPatch,
> nitin
> Fix For: 1.12.0
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There
> are quite a few properties which only affect querying or cost-estimation and
> don't imply a change in indexed data. For such cases, simply setting
> {{refresh=true}} should suffice.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8526:
---
Labels: candidate_oak_1_8 (was: candidate_oak_1_10 candidate_oak_1_8)
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_8
> Fix For: 1.18.0
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899549#comment-16899549
]
Vikas Saurabh edited comment on OAK-8526 at 8/4/19 4:37 AM:
Fixed on trunk at [r1864349|https://svn.apache.org/r1864349].
Backported to 1.10 branch at [r1864352|https://svn.apache.org/r1864352].
was (Author: catholicon):
Fixed on trunk at [r1864349|https://svn.apache.org/r1864349].
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_8
> Fix For: 1.18.0
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-8114) IndexDefinitionBuilder should be smarter when to reindex while updating a definition
[
https://issues.apache.org/jira/browse/OAK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899555#comment-16899555
]
Vikas Saurabh commented on OAK-8114:
Backported to 1.10 branch at [r1864351|https://svn.apache.org/r1864351].
> IndexDefinitionBuilder should be smarter when to reindex while updating a
> definition
>
>
> Key: OAK-8114
> URL: https://issues.apache.org/jira/browse/OAK-8114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, search
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_6,
> candidate_oak_1_8, indexingPatch, nitin
> Fix For: 1.12.0
>
> Attachments: OAK-8114_1.patch, OAK-8114_2.patch
>
>
> {{IndexDefinitionBuilder}} currently sets reindex flag while building an
> index definition if there is a difference in existing def v/s what it builds.
> The only place it acts smarter is while setting up nrt or sync flag. There
> are quite a few properties which only affect querying or cost-estimation and
> don't imply a change in indexed data. For such cases, simply setting
> {{refresh=true}} should suffice.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8526:
---
Labels: candidate_oak_1_10 candidate_oak_1_8 (was: )
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Labels: candidate_oak_1_10, candidate_oak_1_8
> Fix For: 1.18.0
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
[
https://issues.apache.org/jira/browse/OAK-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8526.
Resolution: Fixed
Fix Version/s: 1.18.0
Fixed on trunk at [r1864349|https://svn.apache.org/r1864349].
> IndexDefinitionBuilder should support setting up index tags
> ---
>
> Key: OAK-8526
> URL: https://issues.apache.org/jira/browse/OAK-8526
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.18.0
>
>
> {{IndexDefinitionBuilder}} should support setting up index tags \[0]. We
> should ensure that index tag doesn't kick in reindexing (improve OAK-8114).
> \[0]:
> https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (OAK-8526) IndexDefinitionBuilder should support setting up index tags
Vikas Saurabh created OAK-8526:
--
Summary: IndexDefinitionBuilder should support setting up index
tags
Key: OAK-8526
URL: https://issues.apache.org/jira/browse/OAK-8526
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
{{IndexDefinitionBuilder}} should support setting up index tags \[0]. We should
ensure that index tag doesn't kick in reindexing (improve OAK-8114).
\[0]:
https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Query_Option_Index_Tag
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-8513) Concurrent index access via CopyOnRead directory can lead to reading directly off of remote
[
https://issues.apache.org/jira/browse/OAK-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898571#comment-16898571
]
Vikas Saurabh commented on OAK-8513:
[~tmueller], while I've committed the change, it'd great if you can have a look.
> Concurrent index access via CopyOnRead directory can lead to reading directly
> off of remote
> ---
>
> Key: OAK-8513
> URL: https://issues.apache.org/jira/browse/OAK-8513
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.18.0
>
>
> Even with prefetch enabled having 2 CopyOnRead directories pointing to same
> index can lead to one of the instance reading index files directly off of
> remote index.
> The reason this happens is because {{COR#copyFilesToLocal}} explicitly
> chooses to work with remote if index copier reports that a copy is in
> progress.
> This wasn't a problem earlier when COR was only used via IndexTracker so
> concurrent COR instances weren't expected (COR's avoid local for conc copy
> was probably worried about non-prefetch case).
> But with OAK-8097, {{DefaultDirectoryFactory}} also uses COR to bring the
> files. Which means that if there's a query against an index which is getting
> updated as well then either of COR instance could read directly from remote.
> The condition should only be relevant during early app start up but since
> this can happen in default configuration, we should attempt to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (OAK-8513) Concurrent index access via CopyOnRead directory can lead to reading directly off of remote
[
https://issues.apache.org/jira/browse/OAK-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8513.
Resolution: Fixed
Fix Version/s: 1.18.0
Done on trunk at [r1864197|https://svn.apache.org/r1864197].
> Concurrent index access via CopyOnRead directory can lead to reading directly
> off of remote
> ---
>
> Key: OAK-8513
> URL: https://issues.apache.org/jira/browse/OAK-8513
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.18.0
>
>
> Even with prefetch enabled having 2 CopyOnRead directories pointing to same
> index can lead to one of the instance reading index files directly off of
> remote index.
> The reason this happens is because {{COR#copyFilesToLocal}} explicitly
> chooses to work with remote if index copier reports that a copy is in
> progress.
> This wasn't a problem earlier when COR was only used via IndexTracker so
> concurrent COR instances weren't expected (COR's avoid local for conc copy
> was probably worried about non-prefetch case).
> But with OAK-8097, {{DefaultDirectoryFactory}} also uses COR to bring the
> files. Which means that if there's a query against an index which is getting
> updated as well then either of COR instance could read directly from remote.
> The condition should only be relevant during early app start up but since
> this can happen in default configuration, we should attempt to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (OAK-8525) Document --doc-traversal-mode for oak-run based indexing
Vikas Saurabh created OAK-8525: -- Summary: Document --doc-traversal-mode for oak-run based indexing Key: OAK-8525 URL: https://issues.apache.org/jira/browse/OAK-8525 Project: Jackrabbit Oak Issue Type: Documentation Components: indexing, lucene, oak-run Reporter: Vikas Saurabh -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (OAK-8517) javadoc:aggregate build fails
[
https://issues.apache.org/jira/browse/OAK-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895969#comment-16895969
]
Vikas Saurabh commented on OAK-8517:
[~reschke], btw, I am not completely sure what aggregator does but enabling it
seems to increase time to run {{mvn site -Pdoc,javadoc}} significantly
(hopefully, I'm not doing something wrong)
> javadoc:aggregate build fails
> -
>
> Key: OAK-8517
> URL: https://issues.apache.org/jira/browse/OAK-8517
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: doc
>Reporter: Julian Reschke
>Priority: Major
>
> {{mvn site -Pdoc,javadoc}} fails with:
> {noformat}
> [ERROR]
> /mnt/c/projects/apache/oak/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/JackrabbitNode.java:40:
> error: cannot find symbol
> [ERROR] * @param mixinNames
> [ERROR] ^
> [ERROR] symbol: variable LUCENE_47
> [ERROR] location: class Version
> [ERROR]
> /mnt/c/projects/apache/oak/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/OakCodec.java:41:
> error: reference not found
> [ERROR] * It simply mimics {@link Lucene46Codec} but
> [ERROR]^
> [ERROR]
> [ERROR] Command line was: /home/jre/jdk1.8.0_221/jre/../bin/javadoc @options
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/mnt/c/projects/apache/oak/trunk/oak-doc/target/site/apidocs' dir.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-8517) javadoc:aggregate build fails
[
https://issues.apache.org/jira/browse/OAK-8517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895963#comment-16895963
]
Vikas Saurabh commented on OAK-8517:
[~reschke], I did a bisect between [r1829854|https://svn.apache.org/r1829854]
(one before [r1829855|https://svn.apache.org/r1829855]) to now which reported
{noformat}
commit 8b0af7d499b5008dd3a3dbdd50f83128cec04566
Author: Julian Reschke
Date: Fri Jul 12 14:14:31 2019 +
OAK-8478: remove unneeded javadoc plugin version number from reactor pom
git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1862976
13f79535-47bb-0310-9956-ffa450edef68
:100644 100644 5324e55858d6ae097f3246678c535cb1cd7e533b
b5dda961cc330913c135c3035aa5fa223f7967a2 M pom.xml
{noformat}
to be the offending commit.
oak-parent/pom.xml has maven-javadoc-plugin version set to 3.1.0. So, I guess
this is failing with (due to side-effect) version bump to 3.1.0. Hopefully
that'd take us forward.
> javadoc:aggregate build fails
> -
>
> Key: OAK-8517
> URL: https://issues.apache.org/jira/browse/OAK-8517
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: doc
>Reporter: Julian Reschke
>Priority: Major
>
> {{mvn site -Pdoc,javadoc}} fails with:
> {noformat}
> [ERROR]
> /mnt/c/projects/apache/oak/trunk/oak-jackrabbit-api/src/main/java/org/apache/jackrabbit/api/JackrabbitNode.java:40:
> error: cannot find symbol
> [ERROR] * @param mixinNames
> [ERROR] ^
> [ERROR] symbol: variable LUCENE_47
> [ERROR] location: class Version
> [ERROR]
> /mnt/c/projects/apache/oak/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/OakCodec.java:41:
> error: reference not found
> [ERROR] * It simply mimics {@link Lucene46Codec} but
> [ERROR]^
> [ERROR]
> [ERROR] Command line was: /home/jre/jdk1.8.0_221/jre/../bin/javadoc @options
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/mnt/c/projects/apache/oak/trunk/oak-doc/target/site/apidocs' dir.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (OAK-8513) Concurrent index access via CopyOnRead directory can lead to reading directly off of remote
[
https://issues.apache.org/jira/browse/OAK-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895066#comment-16895066
]
Vikas Saurabh commented on OAK-8513:
Added ignored test case at [r1863918|https://svn.apache.org/r1863918].
> Concurrent index access via CopyOnRead directory can lead to reading directly
> off of remote
> ---
>
> Key: OAK-8513
> URL: https://issues.apache.org/jira/browse/OAK-8513
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>
> Even with prefetch enabled having 2 CopyOnRead directories pointing to same
> index can lead to one of the instance reading index files directly off of
> remote index.
> The reason this happens is because {{COR#copyFilesToLocal}} explicitly
> chooses to work with remote if index copier reports that a copy is in
> progress.
> This wasn't a problem earlier when COR was only used via IndexTracker so
> concurrent COR instances weren't expected (COR's avoid local for conc copy
> was probably worried about non-prefetch case).
> But with OAK-8097, {{DefaultDirectoryFactory}} also uses COR to bring the
> files. Which means that if there's a query against an index which is getting
> updated as well then either of COR instance could read directly from remote.
> The condition should only be relevant during early app start up but since
> this can happen in default configuration, we should attempt to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (OAK-8514) CoR should log a warn when opening remote index file when prefetch is enabled
[ https://issues.apache.org/jira/browse/OAK-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-8514. Resolution: Fixed Fix Version/s: 1.18.0 Done on trunk at [r1863917|https://svn.apache.org/r1863917]. > CoR should log a warn when opening remote index file when prefetch is enabled > - > > Key: OAK-8514 > URL: https://issues.apache.org/jira/browse/OAK-8514 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Fix For: 1.18.0 > > > Currently CoR logs almost everything in trace. It'd be useful to investigate > issues if at least when prefetch is enabled (hence expectation is that all > files should be available locally) then opening index file from remote > directory should be logged as a warn. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (OAK-8497) Remove oak-search-elastic declaration to skip baseline plugin
[
https://issues.apache.org/jira/browse/OAK-8497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-8497.
Resolution: Done
Done on trunk at [r1863916|https://svn.apache.org/r1863916].
> Remove oak-search-elastic declaration to skip baseline plugin
> -
>
> Key: OAK-8497
> URL: https://issues.apache.org/jira/browse/OAK-8497
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: search-elastic
>Affects Versions: 1.16.0
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Fix For: 1.18.0
>
>
> {{oak-search-elastic}} module was introduced in OAK-7981 which would be
> released with 1.16. After that we should remove the baseline skip config:
> {noformat}
>
> baseline
>
> baseline
>
> pre-integration-test
>
>
> true
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (OAK-8497) Remove oak-search-elastic declaration to skip baseline plugin
[
https://issues.apache.org/jira/browse/OAK-8497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh reassigned OAK-8497:
--
Assignee: Vikas Saurabh
> Remove oak-search-elastic declaration to skip baseline plugin
> -
>
> Key: OAK-8497
> URL: https://issues.apache.org/jira/browse/OAK-8497
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: search-elastic
>Affects Versions: 1.16.0
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Blocker
> Fix For: 1.18.0
>
>
> {{oak-search-elastic}} module was introduced in OAK-7981 which would be
> released with 1.16. After that we should remove the baseline skip config:
> {noformat}
>
> baseline
>
> baseline
>
> pre-integration-test
>
>
> true
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (OAK-8514) CoR should log a warn when opening remote index file when prefetch is enabled
Vikas Saurabh created OAK-8514: -- Summary: CoR should log a warn when opening remote index file when prefetch is enabled Key: OAK-8514 URL: https://issues.apache.org/jira/browse/OAK-8514 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Vikas Saurabh Assignee: Vikas Saurabh Currently CoR logs almost everything in trace. It'd be useful to investigate issues if at least when prefetch is enabled (hence expectation is that all files should be available locally) then opening index file from remote directory should be logged as a warn. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-8513) Concurrent index access via CopyOnRead directory can lead to reading directly off of remote
[
https://issues.apache.org/jira/browse/OAK-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8513:
---
Summary: Concurrent index access via CopyOnRead directory can lead to
reading directly off of remote (was: Concurrent access via CopyOnRead
directory can lead to reading directly off of remote)
> Concurrent index access via CopyOnRead directory can lead to reading directly
> off of remote
> ---
>
> Key: OAK-8513
> URL: https://issues.apache.org/jira/browse/OAK-8513
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
>
> Even with prefetch enabled having 2 CopyOnRead directories pointing to same
> index can lead to one of the instance reading index files directly off of
> remote index.
> The reason this happens is because {{COR#copyFilesToLocal}} explicitly
> chooses to work with remote if index copier reports that a copy is in
> progress.
> This wasn't a problem earlier when COR was only used via IndexTracker so
> concurrent COR instances weren't expected (COR's avoid local for conc copy
> was probably worried about non-prefetch case).
> But with OAK-8097, {{DefaultDirectoryFactory}} also uses COR to bring the
> files. Which means that if there's a query against an index which is getting
> updated as well then either of COR instance could read directly from remote.
> The condition should only be relevant during early app start up but since
> this can happen in default configuration, we should attempt to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (OAK-8513) Concurrent access via CopyOnRead directory can lead to reading directly off of remote
Vikas Saurabh created OAK-8513:
--
Summary: Concurrent access via CopyOnRead directory can lead to
reading directly off of remote
Key: OAK-8513
URL: https://issues.apache.org/jira/browse/OAK-8513
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
Even with prefetch enabled having 2 CopyOnRead directories pointing to same
index can lead to one of the instance reading index files directly off of
remote index.
The reason this happens is because {{COR#copyFilesToLocal}} explicitly chooses
to work with remote if index copier reports that a copy is in progress.
This wasn't a problem earlier when COR was only used via IndexTracker so
concurrent COR instances weren't expected (COR's avoid local for conc copy was
probably worried about non-prefetch case).
But with OAK-8097, {{DefaultDirectoryFactory}} also uses COR to bring the
files. Which means that if there's a query against an index which is getting
updated as well then either of COR instance could read directly from remote.
The condition should only be relevant during early app start up but since this
can happen in default configuration, we should attempt to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8512) Without prefetch CopyOnRead opens index files remotely even if they are locally available
[
https://issues.apache.org/jira/browse/OAK-8512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8512:
---
Component/s: lucene
> Without prefetch CopyOnRead opens index files remotely even if they are
> locally available
> -
>
> Key: OAK-8512
> URL: https://issues.apache.org/jira/browse/OAK-8512
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Priority: Trivial
>
> Without prefetch enabled, CopyOnReadDirectory schedules a copy of file when
> {{Directory#openInput}} is invoked. This happens even if there might a copy
> of file completely available already (maybe due to CopyOnWriteDirectory).
> While the scheduled copy would check if the file is valid already but by that
> time often index file are accessed remotely.
> The fix is fairly simple - don't schedule if file exists locally and passes
> our weak test that length matches what we expect \[0].
> But, since we strongly advise to enable prefetch, the priority of the issue
> is minor. Perf impact would be significant during application start so sev
> should high I guess.
> \[0]:
> {noformat}
> $ git diff
> oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> diff --git
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
>
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> index b6b16286d2..d49e5d9ea7 100644
> ---
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> +++
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> @@ -126,11 +126,12 @@ public class CopyOnReadDirectory extends
> FilterDirectory {
> CORFileReference toPut = new CORFileReference(name);
> CORFileReference old = files.putIfAbsent(name, toPut);
> if (old == null) {
> -log.trace("[{}] scheduled local copy for {}", indexPath, name);
> -copy(toPut);
> +if (copy(toPut)) {
> +log.trace("[{}] scheduled local copy for {}", indexPath,
> name);
> +}
> }
>
> -//If immediate executor is used the result would be ready right away
> +//If immediate executor is used OR local file already existed, the
> result would be ready right away
> if (toPut.isLocalValid()) {
> log.trace("[{}] opening new local file {}", indexPath, name);
> return toPut.openLocalInput(context);
> @@ -145,7 +146,21 @@ public class CopyOnReadDirectory extends FilterDirectory
> {
> return local;
> }
>
> -private void copy(final CORFileReference reference) {
> +private boolean copy(final CORFileReference reference) {
> +// quick sanity check
> +if (reference.isLocalValid()) {
> +return false;
> +}
> +try {
> +String name = reference.name;
> +if (local.fileExists(name) && local.fileLength(name) ==
> remote.fileLength(name)) {
> +reference.markValid();
> +return false;
> +}
> +} catch (IOException e) {
> +// ignore
> +}
> +
> indexCopier.scheduledForCopy();
> executor.execute(new Runnable() {
> @Override
> @@ -154,6 +169,8 @@ public class CopyOnReadDirectory extends FilterDirectory {
> copyFilesToLocal(reference, true, true);
> }
> });
> +
> +return true;
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8512) Without prefetch CopyOnRead opens index files remotely even if they are locally available
[
https://issues.apache.org/jira/browse/OAK-8512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8512:
---
Priority: Minor (was: Trivial)
> Without prefetch CopyOnRead opens index files remotely even if they are
> locally available
> -
>
> Key: OAK-8512
> URL: https://issues.apache.org/jira/browse/OAK-8512
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Priority: Minor
>
> Without prefetch enabled, CopyOnReadDirectory schedules a copy of file when
> {{Directory#openInput}} is invoked. This happens even if there might a copy
> of file completely available already (maybe due to CopyOnWriteDirectory).
> While the scheduled copy would check if the file is valid already but by that
> time often index file are accessed remotely.
> The fix is fairly simple - don't schedule if file exists locally and passes
> our weak test that length matches what we expect \[0].
> But, since we strongly advise to enable prefetch, the priority of the issue
> is minor. Perf impact would be significant during application start so sev
> should high I guess.
> \[0]:
> {noformat}
> $ git diff
> oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> diff --git
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
>
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> index b6b16286d2..d49e5d9ea7 100644
> ---
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> +++
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> @@ -126,11 +126,12 @@ public class CopyOnReadDirectory extends
> FilterDirectory {
> CORFileReference toPut = new CORFileReference(name);
> CORFileReference old = files.putIfAbsent(name, toPut);
> if (old == null) {
> -log.trace("[{}] scheduled local copy for {}", indexPath, name);
> -copy(toPut);
> +if (copy(toPut)) {
> +log.trace("[{}] scheduled local copy for {}", indexPath,
> name);
> +}
> }
>
> -//If immediate executor is used the result would be ready right away
> +//If immediate executor is used OR local file already existed, the
> result would be ready right away
> if (toPut.isLocalValid()) {
> log.trace("[{}] opening new local file {}", indexPath, name);
> return toPut.openLocalInput(context);
> @@ -145,7 +146,21 @@ public class CopyOnReadDirectory extends FilterDirectory
> {
> return local;
> }
>
> -private void copy(final CORFileReference reference) {
> +private boolean copy(final CORFileReference reference) {
> +// quick sanity check
> +if (reference.isLocalValid()) {
> +return false;
> +}
> +try {
> +String name = reference.name;
> +if (local.fileExists(name) && local.fileLength(name) ==
> remote.fileLength(name)) {
> +reference.markValid();
> +return false;
> +}
> +} catch (IOException e) {
> +// ignore
> +}
> +
> indexCopier.scheduledForCopy();
> executor.execute(new Runnable() {
> @Override
> @@ -154,6 +169,8 @@ public class CopyOnReadDirectory extends FilterDirectory {
> copyFilesToLocal(reference, true, true);
> }
> });
> +
> +return true;
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8512) Without prefetch CopyOnRead opens index files remotely even if they are locally available
[
https://issues.apache.org/jira/browse/OAK-8512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8512:
---
Summary: Without prefetch CopyOnRead opens index files remotely even if
they are locally available (was: Without prefetch CopyOnRead opens index file
remoted)
> Without prefetch CopyOnRead opens index files remotely even if they are
> locally available
> -
>
> Key: OAK-8512
> URL: https://issues.apache.org/jira/browse/OAK-8512
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Vikas Saurabh
>Priority: Trivial
>
> Without prefetch enabled, CopyOnReadDirectory schedules a copy of file when
> {{Directory#openInput}} is invoked. This happens even if there might a copy
> of file completely available already (maybe due to CopyOnWriteDirectory).
> While the scheduled copy would check if the file is valid already but by that
> time often index file are accessed remotely.
> The fix is fairly simple - don't schedule if file exists locally and passes
> our weak test that length matches what we expect \[0].
> But, since we strongly advise to enable prefetch, the priority of the issue
> is minor. Perf impact would be significant during application start so sev
> should high I guess.
> \[0]:
> {noformat}
> $ git diff
> oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> diff --git
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
>
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> index b6b16286d2..d49e5d9ea7 100644
> ---
> a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> +++
> b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
> @@ -126,11 +126,12 @@ public class CopyOnReadDirectory extends
> FilterDirectory {
> CORFileReference toPut = new CORFileReference(name);
> CORFileReference old = files.putIfAbsent(name, toPut);
> if (old == null) {
> -log.trace("[{}] scheduled local copy for {}", indexPath, name);
> -copy(toPut);
> +if (copy(toPut)) {
> +log.trace("[{}] scheduled local copy for {}", indexPath,
> name);
> +}
> }
>
> -//If immediate executor is used the result would be ready right away
> +//If immediate executor is used OR local file already existed, the
> result would be ready right away
> if (toPut.isLocalValid()) {
> log.trace("[{}] opening new local file {}", indexPath, name);
> return toPut.openLocalInput(context);
> @@ -145,7 +146,21 @@ public class CopyOnReadDirectory extends FilterDirectory
> {
> return local;
> }
>
> -private void copy(final CORFileReference reference) {
> +private boolean copy(final CORFileReference reference) {
> +// quick sanity check
> +if (reference.isLocalValid()) {
> +return false;
> +}
> +try {
> +String name = reference.name;
> +if (local.fileExists(name) && local.fileLength(name) ==
> remote.fileLength(name)) {
> +reference.markValid();
> +return false;
> +}
> +} catch (IOException e) {
> +// ignore
> +}
> +
> indexCopier.scheduledForCopy();
> executor.execute(new Runnable() {
> @Override
> @@ -154,6 +169,8 @@ public class CopyOnReadDirectory extends FilterDirectory {
> copyFilesToLocal(reference, true, true);
> }
> });
> +
> +return true;
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-8512) Without prefetch CopyOnRead opens index file remoted
[
https://issues.apache.org/jira/browse/OAK-8512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-8512:
---
Description:
Without prefetch enabled, CopyOnReadDirectory schedules a copy of file when
{{Directory#openInput}} is invoked. This happens even if there might a copy of
file completely available already (maybe due to CopyOnWriteDirectory). While
the scheduled copy would check if the file is valid already but by that time
often index file are accessed remotely.
The fix is fairly simple - don't schedule if file exists locally and passes our
weak test that length matches what we expect \[0].
But, since we strongly advise to enable prefetch, the priority of the issue is
minor. Perf impact would be significant during application start so sev should
high I guess.
\[0]:
{noformat}
$ git diff
oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
diff --git
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
index b6b16286d2..d49e5d9ea7 100644
---
a/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
+++
b/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/directory/CopyOnReadDirectory.java
@@ -126,11 +126,12 @@ public class CopyOnReadDirectory extends FilterDirectory {
CORFileReference toPut = new CORFileReference(name);
CORFileReference old = files.putIfAbsent(name, toPut);
if (old == null) {
-log.trace("[{}] scheduled local copy for {}", indexPath, name);
-copy(toPut);
+if (copy(toPut)) {
+log.trace("[{}] scheduled local copy for {}", indexPath, name);
+}
}
-//If immediate executor is used the result would be ready right away
+//If immediate executor is used OR local file already existed, the
result would be ready right away
if (toPut.isLocalValid()) {
log.trace("[{}] opening new local file {}", indexPath, name);
return toPut.openLocalInput(context);
@@ -145,7 +146,21 @@ public class CopyOnReadDirectory extends FilterDirectory {
return local;
}
-private void copy(final CORFileReference reference) {
+private boolean copy(final CORFileReference reference) {
+// quick sanity check
+if (reference.isLocalValid()) {
+return false;
+}
+try {
+String name = reference.name;
+if (local.fileExists(name) && local.fileLength(name) ==
remote.fileLength(name)) {
+reference.markValid();
+return false;
+}
+} catch (IOException e) {
+// ignore
+}
+
indexCopier.scheduledForCopy();
executor.execute(new Runnable() {
@Override
@@ -154,6 +169,8 @@ public class CopyOnReadDirectory extends FilterDirectory {
copyFilesToLocal(reference, true, true);
}
});
+
+return true;
}
{noformat}
was:
Without prefetch enabled, CopyOnReadDirectory schedules a copy of file when
{{Directory#openInput}} is invoked. This happens even if there might a copy of
file completely available already (maybe due to CopyOnWriteDirectory). While
the scheduled copy would check if the file is valid already but by that time
often index file are accessed remotely.
The fix is fairly simple - don't schedule if file exists locally and passes our
weak test that length matches what we expect.
But, since we strongly advise to enable prefetch, the priority of the issue is
minor. Perf impact would be significant during application start so sev should
high I guess.
> Without prefetch CopyOnRead opens index file remoted
>
>
> Key: OAK-8512
> URL: https://issues.apache.org/jira/browse/OAK-8512
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Vikas Saurabh
>Priority: Trivial
>
> Without prefetch enabled, CopyOnReadDirectory schedules a copy of file when
> {{Directory#openInput}} is invoked. This happens even if there might a copy
> of file completely available already (maybe due to CopyOnWriteDirectory).
> While the scheduled copy would check if the file is valid already but by that
> time often index file are accessed remotely.
> The fix is fairly simple - don't schedule if file exists locally and passes
> our weak test that length matches what we expect \[0].
> But, since we strongly advise to enable prefetch, the priority of the issue
> is minor. Perf impact would be significant during application start so sev
> should high I guess.
>
[jira] [Created] (OAK-8512) Without prefetch CopyOnRead opens index file remoted
Vikas Saurabh created OAK-8512:
--
Summary: Without prefetch CopyOnRead opens index file remoted
Key: OAK-8512
URL: https://issues.apache.org/jira/browse/OAK-8512
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Vikas Saurabh
Without prefetch enabled, CopyOnReadDirectory schedules a copy of file when
{{Directory#openInput}} is invoked. This happens even if there might a copy of
file completely available already (maybe due to CopyOnWriteDirectory). While
the scheduled copy would check if the file is valid already but by that time
often index file are accessed remotely.
The fix is fairly simple - don't schedule if file exists locally and passes our
weak test that length matches what we expect.
But, since we strongly advise to enable prefetch, the priority of the issue is
minor. Perf impact would be significant during application start so sev should
high I guess.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (OAK-8509) IndexDefinitionBuilder to allow for useInSimilarity
[ https://issues.apache.org/jira/browse/OAK-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh resolved OAK-8509. Resolution: Invalid This already exists in oak-lucene/IndexDefinitionBuilder via OAK-7575. > IndexDefinitionBuilder to allow for useInSimilarity > --- > > Key: OAK-8509 > URL: https://issues.apache.org/jira/browse/OAK-8509 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: search >Reporter: Vikas Saurabh >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (OAK-8509) IndexDefinitionBuilder to allow for useInSimilarity
Vikas Saurabh created OAK-8509: -- Summary: IndexDefinitionBuilder to allow for useInSimilarity Key: OAK-8509 URL: https://issues.apache.org/jira/browse/OAK-8509 Project: Jackrabbit Oak Issue Type: Improvement Components: search Reporter: Vikas Saurabh -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (OAK-5950) XPath: stack overflow for large combination of "or" and "and"
[
https://issues.apache.org/jira/browse/OAK-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-5950:
---
Fix Version/s: (was: 1.16.0)
1.18.0
> XPath: stack overflow for large combination of "or" and "and"
> -
>
> Key: OAK-5950
> URL: https://issues.apache.org/jira/browse/OAK-5950
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Priority: Critical
> Fix For: 1.18.0
>
>
> The following query returns in a stack overflow:
> {noformat}
> xpath2sql /jcr:root/home//element(*,rep:Authorizable)[(@a1=1 or @a2=1 or
> @a3=1 or @a4=1 or @a5=1 or @a6=1 or @a7=1 or @a8=1)
> and (@b1=1 or @b2=1 or @b3=1 or @b4=1 or @b5=1 or @b6=1 or @b7=1 or @b8=1)
> and (@c1=1 or @c2=1 or @c3=1 or @c4=1 or @c5=1 or @c6=1 or @c7=1 or @c8=1)
> and (@d1=1 or @d2=1 or @d3=1 or @d4=1 or @d5=1 or @d6=1 or @d7=1 or @d8=1)]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (OAK-6309) Not always convert XPath "primaryType in a, b" to union
[
https://issues.apache.org/jira/browse/OAK-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-6309:
---
Fix Version/s: (was: 1.16.0)
1.18.0
> Not always convert XPath "primaryType in a, b" to union
> ---
>
> Key: OAK-6309
> URL: https://issues.apache.org/jira/browse/OAK-6309
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.18.0
>
>
> Currently, queries with multiple primary types are always converted to a
> "union", but this is not alway the best solution. The main problem is that
> results are not sorted by score as expected. Example:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (@jcr:primaryType = 'acme:Page' or @jcr:primaryType = 'acme:Asset')]
> {noformat}
> This is currently converted to a union, even if the same index is used for
> buth subqueries (assuming there is an index on nt:hierarchyNode).
> A workaround is to use:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (./@jcr:primaryType = 'acme:Page' or ./@jcr:primaryType = 'acme:Asset')]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
