[jira] [Created] (OAK-10905) Create a configurable job to create checkpoints at a defined interval of time
Nitin Gupta created OAK-10905: - Summary: Create a configurable job to create checkpoints at a defined interval of time Key: OAK-10905 URL: https://issues.apache.org/jira/browse/OAK-10905 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Nitin Gupta The job should be configurable - # To define what interval should the checkpoints be created at - essentially the interval at which the job will run # The logic of how many concurrent checkpoints to keep at a given point of time # Configurable metadata for checkpoints # Job should be disabled by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10905) Create a configurable job to create checkpoints at a defined interval of time
[ https://issues.apache.org/jira/browse/OAK-10905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10905: - Assignee: Nitin Gupta > Create a configurable job to create checkpoints at a defined interval of time > - > > Key: OAK-10905 > URL: https://issues.apache.org/jira/browse/OAK-10905 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > The job should be configurable - > # To define what interval should the checkpoints be created at - essentially > the interval at which the job will run > # The logic of how many concurrent checkpoints to keep at a given point of > time > # Configurable metadata for checkpoints > # Job should be disabled by default. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10874) Force Update a failing indexing lane using a jmx method
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855786#comment-17855786 ] Nitin Gupta edited comment on OAK-10874 at 6/18/24 5:00 AM: trunk : [https://github.com/apache/jackrabbit-oak/commit/cf51f98e999c82bca2e456c58e58dd77c0903d09|cf51f] was (Author: nitigup): [https://github.com/apache/jackrabbit-oak/commit/cf51f98e999c82bca2e456c58e58dd77c0903d09] > Force Update a failing indexing lane using a jmx method > --- > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > JMX should expose a method to force update a failing index lane by - > # Abort and pause the lane > # release the lease > # Create a new checkpoint > # update the lane to refer the new checkpoint > # delete old checkpoint > # resume lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10874) Force Update a failing indexing lane using a jmx method
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855786#comment-17855786 ] Nitin Gupta edited comment on OAK-10874 at 6/18/24 5:00 AM: trunk : [cf51f|https://github.com/apache/jackrabbit-oak/commit/cf51f98e999c82bca2e456c58e58dd77c0903d09] was (Author: nitigup): trunk : [https://github.com/apache/jackrabbit-oak/commit/cf51f98e999c82bca2e456c58e58dd77c0903d09|cf51f] > Force Update a failing indexing lane using a jmx method > --- > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > JMX should expose a method to force update a failing index lane by - > # Abort and pause the lane > # release the lease > # Create a new checkpoint > # update the lane to refer the new checkpoint > # delete old checkpoint > # resume lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10874) Force Update a failing indexing lane using a jmx method
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10874. --- Fix Version/s: 1.66.0 Resolution: Fixed > Force Update a failing indexing lane using a jmx method > --- > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.66.0 > > > JMX should expose a method to force update a failing index lane by - > # Abort and pause the lane > # release the lease > # Create a new checkpoint > # update the lane to refer the new checkpoint > # delete old checkpoint > # resume lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10874) Force Update a failing indexing lane using a jmx method
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855786#comment-17855786 ] Nitin Gupta commented on OAK-10874: --- [https://github.com/apache/jackrabbit-oak/commit/cf51f98e999c82bca2e456c58e58dd77c0903d09] > Force Update a failing indexing lane using a jmx method > --- > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > JMX should expose a method to force update a failing index lane by - > # Abort and pause the lane > # release the lease > # Create a new checkpoint > # update the lane to refer the new checkpoint > # delete old checkpoint > # resume lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10874) Force Update a failing indexing lane using a jmx method
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta updated OAK-10874: -- Description: JMX should expose a method to force update a failing index lane by - # Abort and pause the lane # release the lease # Create a new checkpoint # update the lane to refer the new checkpoint # delete old checkpoint # resume lane was:JMX should expose a method to update the checkpoint for a given async indexing lane > Force Update a failing indexing lane using a jmx method > --- > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > JMX should expose a method to force update a failing index lane by - > # Abort and pause the lane > # release the lease > # Create a new checkpoint > # update the lane to refer the new checkpoint > # delete old checkpoint > # resume lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10874) Update the checkpoint for a lane from JMX
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854671#comment-17854671 ] Nitin Gupta commented on OAK-10874: --- PR : [https://github.com/apache/jackrabbit-oak/pull/1522/files] > Update the checkpoint for a lane from JMX > - > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > JMX should expose a method to update the checkpoint for a given async > indexing lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10874) Force Update a failing indexing lane using a jmx method
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta updated OAK-10874: -- Summary: Force Update a failing indexing lane using a jmx method (was: Update the checkpoint for a lane from JMX) > Force Update a failing indexing lane using a jmx method > --- > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > JMX should expose a method to update the checkpoint for a given async > indexing lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-10781) Access Token refresh in oak-blob-cloud-azure
[ https://issues.apache.org/jira/browse/OAK-10781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reopened OAK-10781: --- > Access Token refresh in oak-blob-cloud-azure > > > Key: OAK-10781 > URL: https://issues.apache.org/jira/browse/OAK-10781 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Mohit Kataria >Priority: Major > Fix For: 1.66.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10874) Update the checkpoint for a lane from JMX
Nitin Gupta created OAK-10874: - Summary: Update the checkpoint for a lane from JMX Key: OAK-10874 URL: https://issues.apache.org/jira/browse/OAK-10874 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Nitin Gupta JMX should expose a method to update the checkpoint for a given async indexing lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10874) Update the checkpoint for a lane from JMX
[ https://issues.apache.org/jira/browse/OAK-10874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10874: - Assignee: Nitin Gupta > Update the checkpoint for a lane from JMX > - > > Key: OAK-10874 > URL: https://issues.apache.org/jira/browse/OAK-10874 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > JMX should expose a method to update the checkpoint for a given async > indexing lane -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10867) Service Principal Support in oak-run-commons
Nitin Gupta created OAK-10867: - Summary: Service Principal Support in oak-run-commons Key: OAK-10867 URL: https://issues.apache.org/jira/browse/OAK-10867 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Nitin Gupta -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10806) Expose Elastic indexes active status in OakIndexStats
Nitin Gupta created OAK-10806: - Summary: Expose Elastic indexes active status in OakIndexStats Key: OAK-10806 URL: https://issues.apache.org/jira/browse/OAK-10806 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Nitin Gupta ES indexes are currently present in the OakIndexStats but they are all shown as active. We should make sure only the latest version of the ES indexes are shown as active. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9481) avoid range queries on like conditions
[ https://issues.apache.org/jira/browse/OAK-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844871#comment-17844871 ] Nitin Gupta commented on OAK-9481: -- Backported to 1.22 branch as well - [https://github.com/apache/jackrabbit-oak/commit/3c6196a9a1ff90564d87b8692568318c54042c37] > avoid range queries on like conditions > -- > > Key: OAK-9481 > URL: https://issues.apache.org/jira/browse/OAK-9481 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, search >Reporter: Fabrizio Fortino >Assignee: Fabrizio Fortino >Priority: Major > Fix For: 1.42.0, 1.22.20 > > > When a query contains a like condition this gets transformed in a range query > in lucene. On multi-value properties, this scans more results than needed. > Although the final results are correct, the response time is affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-9481) avoid range queries on like conditions
[ https://issues.apache.org/jira/browse/OAK-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta updated OAK-9481: - Fix Version/s: 1.22.20 > avoid range queries on like conditions > -- > > Key: OAK-9481 > URL: https://issues.apache.org/jira/browse/OAK-9481 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, search >Reporter: Fabrizio Fortino >Assignee: Fabrizio Fortino >Priority: Major > Fix For: 1.42.0, 1.22.20 > > > When a query contains a like condition this gets transformed in a range query > in lucene. On multi-value properties, this scans more results than needed. > Although the final results are correct, the response time is affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10790) FullTextBinaryTextExtractor incorrectly identifies a text file as CSV and fails while parsing it
Nitin Gupta created OAK-10790:
-
Summary: FullTextBinaryTextExtractor incorrectly identifies a text
file as CSV and fails while parsing it
Key: OAK-10790
URL: https://issues.apache.org/jira/browse/OAK-10790
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Nitin Gupta
FullTextBinaryTextExtractor incorrectly identifies a text file as CSV and fails
while parsing it.
A text file consisting of content with a strucutre similar to a CSV file like -
{code:java}
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
{code}
even the extension of .txt gets parsed by CSV parser via the AutoDetectorParser
in tika.
This leads to a run time exception in an OSGI based setup if the commons-csv
bundle is not provided.
{code:java}
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/csv/CSVFormat
at
org.apache.tika.parser.csv.TextAndCSVParser.parse(TextAndCSVParser.java:169)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:281)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:281)
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143)
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:159)
at
org.apache.jackrabbit.oak.osgi.TikaExtractionOsgiIT.assertFileContains(TikaExtractionOsgiIT.java:215)
at
org.apache.jackrabbit.oak.osgi.TikaExtractionOsgiIT.text2(TikaExtractionOsgiIT.java:204)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
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.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runLeafWithRetry(ContainerTestRunner.java:97)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChildWithRetry(ContainerTestRunner.java:84)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:75)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:43)
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.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
... 25 more {code}
I will add a test to demonstrate this.
We should handle this gracefully in oak and maybe use the parser based on the
file extension or mime type as a backup for the AutoDetectParser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10776) Incremental FFS should filter out changes under paths excluded by pipelinedMongoCustomExcludedPaths
[ https://issues.apache.org/jira/browse/OAK-10776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10776. --- Fix Version/s: 1.64.0 Resolution: Fixed > Incremental FFS should filter out changes under paths excluded by > pipelinedMongoCustomExcludedPaths > --- > > Key: OAK-10776 > URL: https://issues.apache.org/jira/browse/OAK-10776 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.64.0 > > > Pipelined FFS introduced changes to add ability to exclude custom paths via > pipelinedMongoCustomExcludedPaths. > This should be supported in inc ffs diff as well. > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10776) Incremental FFS should filter out changes under paths excluded by pipelinedMongoCustomExcludedPaths
[ https://issues.apache.org/jira/browse/OAK-10776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844517#comment-17844517 ] Nitin Gupta commented on OAK-10776: --- trunk : [https://github.com/apache/jackrabbit-oak/commit/f0ac80ebd85363e36fc71150c334c3665b9d7631] > Incremental FFS should filter out changes under paths excluded by > pipelinedMongoCustomExcludedPaths > --- > > Key: OAK-10776 > URL: https://issues.apache.org/jira/browse/OAK-10776 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Pipelined FFS introduced changes to add ability to exclude custom paths via > pipelinedMongoCustomExcludedPaths. > This should be supported in inc ffs diff as well. > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10776) Incremental FFS should filter out changes under paths excluded by pipelinedMongoCustomExcludedPaths
[ https://issues.apache.org/jira/browse/OAK-10776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842921#comment-17842921 ] Nitin Gupta commented on OAK-10776: --- [https://github.com/apache/jackrabbit-oak/pull/1437/fileshttps://github.com/apache/jackrabbit-oak/pull/1437/files] PR > Incremental FFS should filter out changes under paths excluded by > pipelinedMongoCustomExcludedPaths > --- > > Key: OAK-10776 > URL: https://issues.apache.org/jira/browse/OAK-10776 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Pipelined FFS introduced changes to add ability to exclude custom paths via > pipelinedMongoCustomExcludedPaths. > This should be supported in inc ffs diff as well. > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-6773) Convert oak-store-composite to OSGi R7 annotations
[ https://issues.apache.org/jira/browse/OAK-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842252#comment-17842252 ] Nitin Gupta commented on OAK-6773: -- Commit [https://github.com/apache/jackrabbit-oak/commit/ac1a6b2ff55c54ccc37e33dc8ba807327d064d77] had to be reverted since it introduces a major version in bump in public apis and can potentially break downstream projects. We should see if we can avoid the major version change here. > Convert oak-store-composite to OSGi R7 annotations > -- > > Key: OAK-6773 > URL: https://issues.apache.org/jira/browse/OAK-6773 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: composite >Reporter: Robert Munteanu >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.64.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-6773) Convert oak-store-composite to OSGi R7 annotations
[ https://issues.apache.org/jira/browse/OAK-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reopened OAK-6773: -- > Convert oak-store-composite to OSGi R7 annotations > -- > > Key: OAK-6773 > URL: https://issues.apache.org/jira/browse/OAK-6773 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: composite >Reporter: Robert Munteanu >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.64.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10776) Incremental FFS should filter out changes under paths excluded by pipelinedMongoCustomExcludedPaths
[ https://issues.apache.org/jira/browse/OAK-10776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10776: - Assignee: Nitin Gupta > Incremental FFS should filter out changes under paths excluded by > pipelinedMongoCustomExcludedPaths > --- > > Key: OAK-10776 > URL: https://issues.apache.org/jira/browse/OAK-10776 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Pipelined FFS introduced changes to add ability to exclude custom paths via > pipelinedMongoCustomExcludedPaths. > This should be supported in inc ffs diff as well. > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10776) Incremental FFS should filter out changes under paths excluded by pipelinedMongoCustomExcludedPaths
Nitin Gupta created OAK-10776: - Summary: Incremental FFS should filter out changes under paths excluded by pipelinedMongoCustomExcludedPaths Key: OAK-10776 URL: https://issues.apache.org/jira/browse/OAK-10776 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta Pipelined FFS introduced changes to add ability to exclude custom paths via pipelinedMongoCustomExcludedPaths. This should be supported in inc ffs diff as well. h4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10766) Make lease timeout configurable for specific async lanes in indexing
[ https://issues.apache.org/jira/browse/OAK-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10766. --- Fix Version/s: 1.64.0 Resolution: Fixed > Make lease timeout configurable for specific async lanes in indexing > > > Key: OAK-10766 > URL: https://issues.apache.org/jira/browse/OAK-10766 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.64.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10766) Make lease timeout configurable for specific async lanes in indexing
[ https://issues.apache.org/jira/browse/OAK-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839605#comment-17839605 ] Nitin Gupta commented on OAK-10766: --- trunk : [https://github.com/apache/jackrabbit-oak/commit/c4222079a9842ed3aacdafe6529679b7c74347ba] > Make lease timeout configurable for specific async lanes in indexing > > > Key: OAK-10766 > URL: https://issues.apache.org/jira/browse/OAK-10766 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10773) LuceneIndexLookupUtil opens up index node when it's actually not needed
[ https://issues.apache.org/jira/browse/OAK-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839594#comment-17839594 ] Nitin Gupta commented on OAK-10773: --- trunk : [https://github.com/apache/jackrabbit-oak/commit/4fdc15ff803907dc1606f5bf55c474ec7ca310ef] > LuceneIndexLookupUtil opens up index node when it's actually not needed > --- > > Key: OAK-10773 > URL: https://issues.apache.org/jira/browse/OAK-10773 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > We try and aquire the index node here > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexLookupUtil.java#L49] > which would lead to the index binaries getting downloaded if they are not > synced locally. > > This is not really required here since all we need is the index definition > object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10773) LuceneIndexLookupUtil opens up index node when it's actually not needed
[ https://issues.apache.org/jira/browse/OAK-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10773. --- Fix Version/s: 1.64.0 Resolution: Fixed > LuceneIndexLookupUtil opens up index node when it's actually not needed > --- > > Key: OAK-10773 > URL: https://issues.apache.org/jira/browse/OAK-10773 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.64.0 > > > We try and aquire the index node here > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexLookupUtil.java#L49] > which would lead to the index binaries getting downloaded if they are not > synced locally. > > This is not really required here since all we need is the index definition > object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10773) LuceneIndexLookupUtil opens up index node when it's actually not needed
[ https://issues.apache.org/jira/browse/OAK-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839484#comment-17839484 ] Nitin Gupta commented on OAK-10773: --- PR = [https://github.com/apache/jackrabbit-oak/pull/1432] > LuceneIndexLookupUtil opens up index node when it's actually not needed > --- > > Key: OAK-10773 > URL: https://issues.apache.org/jira/browse/OAK-10773 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > We try and aquire the index node here > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexLookupUtil.java#L49] > which would lead to the index binaries getting downloaded if they are not > synced locally. > > This is not really required here since all we need is the index definition > object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10773) LuceneIndexLookupUtil opens up index node when it's actually not needed
[ https://issues.apache.org/jira/browse/OAK-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10773: - Assignee: Nitin Gupta > LuceneIndexLookupUtil opens up index node when it's actually not needed > --- > > Key: OAK-10773 > URL: https://issues.apache.org/jira/browse/OAK-10773 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > We try and aquire the index node here > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexLookupUtil.java#L49] > which would lead to the index binaries getting downloaded if they are not > synced locally. > > This is not really required here since all we need is the index definition > object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10773) LuceneIndexLookupUtil opens up index node when it's actually not needed
Nitin Gupta created OAK-10773: - Summary: LuceneIndexLookupUtil opens up index node when it's actually not needed Key: OAK-10773 URL: https://issues.apache.org/jira/browse/OAK-10773 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta We try and aquire the index node here [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexLookupUtil.java#L49] which would lead to the index binaries getting downloaded if they are not synced locally. This is not really required here since all we need is the index definition object. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10770) Azure identity runtime dependency resolution in oak-segment-azure
Nitin Gupta created OAK-10770: - Summary: Azure identity runtime dependency resolution in oak-segment-azure Key: OAK-10770 URL: https://issues.apache.org/jira/browse/OAK-10770 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10766) Make lease timeout configurable for specific async lanes in indexing
Nitin Gupta created OAK-10766: - Summary: Make lease timeout configurable for specific async lanes in indexing Key: OAK-10766 URL: https://issues.apache.org/jira/browse/OAK-10766 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10766) Make lease timeout configurable for specific async lanes in indexing
[ https://issues.apache.org/jira/browse/OAK-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10766: - Assignee: Nitin Gupta > Make lease timeout configurable for specific async lanes in indexing > > > Key: OAK-10766 > URL: https://issues.apache.org/jira/browse/OAK-10766 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10733) Filter out hidden properties from content in FlatFileStore
[ https://issues.apache.org/jira/browse/OAK-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10733. --- Resolution: Won't Fix > Filter out hidden properties from content in FlatFileStore > -- > > Key: OAK-10733 > URL: https://issues.apache.org/jira/browse/OAK-10733 > Project: Jackrabbit Oak > Issue Type: Task > Components: run-commons >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Currently we ignore/filter out hidden nodes while building the FFS but not > the hidden properties. > We however ignore any changes to hidden properties (using the VisibleEditor) > during async indexing cycles, so it makes little sense to have these in the > FFS. > > This task is to see if these can be removed, and if gives some benefit during > reindexing phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10733) Filter out hidden properties from content in FlatFileStore
[ https://issues.apache.org/jira/browse/OAK-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837943#comment-17837943 ] Nitin Gupta commented on OAK-10733: --- No longer required. > Filter out hidden properties from content in FlatFileStore > -- > > Key: OAK-10733 > URL: https://issues.apache.org/jira/browse/OAK-10733 > Project: Jackrabbit Oak > Issue Type: Task > Components: run-commons >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Currently we ignore/filter out hidden nodes while building the FFS but not > the hidden properties. > We however ignore any changes to hidden properties (using the VisibleEditor) > during async indexing cycles, so it makes little sense to have these in the > FFS. > > This task is to see if these can be removed, and if gives some benefit during > reindexing phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10733) Filter out hidden properties from content in FlatFileStore
[ https://issues.apache.org/jira/browse/OAK-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833657#comment-17833657 ] Nitin Gupta commented on OAK-10733: --- Reverted the commit here [https://github.com/apache/jackrabbit-oak/commit/e220c69ec73f1cf8012d6f702a8eb1d386a4418e] . The seems to be due to the isEmpty() check. I will create a new PR. > Filter out hidden properties from content in FlatFileStore > -- > > Key: OAK-10733 > URL: https://issues.apache.org/jira/browse/OAK-10733 > Project: Jackrabbit Oak > Issue Type: Task > Components: run-commons >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Currently we ignore/filter out hidden nodes while building the FFS but not > the hidden properties. > We however ignore any changes to hidden properties (using the VisibleEditor) > during async indexing cycles, so it makes little sense to have these in the > FFS. > > This task is to see if these can be removed, and if gives some benefit during > reindexing phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10733) Filter out hidden properties from content in FlatFileStore
[ https://issues.apache.org/jira/browse/OAK-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10733. --- Fix Version/s: 1.62.0 Resolution: Fixed > Filter out hidden properties from content in FlatFileStore > -- > > Key: OAK-10733 > URL: https://issues.apache.org/jira/browse/OAK-10733 > Project: Jackrabbit Oak > Issue Type: Task > Components: run-commons >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.62.0 > > > Currently we ignore/filter out hidden nodes while building the FFS but not > the hidden properties. > We however ignore any changes to hidden properties (using the VisibleEditor) > during async indexing cycles, so it makes little sense to have these in the > FFS. > > This task is to see if these can be removed, and if gives some benefit during > reindexing phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10733) Filter out hidden properties from content in FlatFileStore
[ https://issues.apache.org/jira/browse/OAK-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833537#comment-17833537 ] Nitin Gupta commented on OAK-10733: --- trunk : [https://github.com/apache/jackrabbit-oak/commit/2b27df56b9901fe107bcad6aed03c402234f590a] > Filter out hidden properties from content in FlatFileStore > -- > > Key: OAK-10733 > URL: https://issues.apache.org/jira/browse/OAK-10733 > Project: Jackrabbit Oak > Issue Type: Task > Components: run-commons >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Currently we ignore/filter out hidden nodes while building the FFS but not > the hidden properties. > We however ignore any changes to hidden properties (using the VisibleEditor) > during async indexing cycles, so it makes little sense to have these in the > FFS. > > This task is to see if these can be removed, and if gives some benefit during > reindexing phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10733) Filter out hidden properties from content in FlatFileStore
[ https://issues.apache.org/jira/browse/OAK-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10733: - Assignee: Nitin Gupta > Filter out hidden properties from content in FlatFileStore > -- > > Key: OAK-10733 > URL: https://issues.apache.org/jira/browse/OAK-10733 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > Currently we ignore/filter out hidden nodes while building the FFS but not > the hidden properties. > We however ignore any changes to hidden properties (using the VisibleEditor) > during async indexing cycles, so it makes little sense to have these in the > FFS. > > This task is to see if these can be removed, and if gives some benefit during > reindexing phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10733) Filter out hidden properties from content in FlatFileStore
Nitin Gupta created OAK-10733: - Summary: Filter out hidden properties from content in FlatFileStore Key: OAK-10733 URL: https://issues.apache.org/jira/browse/OAK-10733 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta Currently we ignore/filter out hidden nodes while building the FFS but not the hidden properties. We however ignore any changes to hidden properties (using the VisibleEditor) during async indexing cycles, so it makes little sense to have these in the FFS. This task is to see if these can be removed, and if gives some benefit during reindexing phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10693) Incremental FFS build should filter out paths based on mongo regex filters
[ https://issues.apache.org/jira/browse/OAK-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825276#comment-17825276 ] Nitin Gupta commented on OAK-10693: --- trunk : [https://github.com/apache/jackrabbit-oak/commit/0319de9c87acffd21edfd7a4bd8a069fb580c8ba] > Incremental FFS build should filter out paths based on mongo regex filters > -- > > Key: OAK-10693 > URL: https://issues.apache.org/jira/browse/OAK-10693 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > As part of https://issues.apache.org/jira/browse/OAK-10681 , support for > custom filters was added to build the base FFS using pipelined approach. We > need to add similar support for the incremental FFS builds as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10693) Incremental FFS build should filter out paths based on mongo regex filters
[ https://issues.apache.org/jira/browse/OAK-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10693. --- Fix Version/s: 1.62.0 Resolution: Fixed > Incremental FFS build should filter out paths based on mongo regex filters > -- > > Key: OAK-10693 > URL: https://issues.apache.org/jira/browse/OAK-10693 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.62.0 > > > As part of https://issues.apache.org/jira/browse/OAK-10681 , support for > custom filters was added to build the base FFS using pipelined approach. We > need to add similar support for the incremental FFS builds as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10693) Incremental FFS build should filter out paths based on mongo regex filters
[ https://issues.apache.org/jira/browse/OAK-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10693: - Assignee: Nitin Gupta > Incremental FFS build should filter out paths based on mongo regex filters > -- > > Key: OAK-10693 > URL: https://issues.apache.org/jira/browse/OAK-10693 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > As part of https://issues.apache.org/jira/browse/OAK-10681 , support for > custom filters was added to build the base FFS using pipelined approach. We > need to add similar support for the incremental FFS builds as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10693) Incremental FFS build should filter out paths based on mongo regex filters
Nitin Gupta created OAK-10693: - Summary: Incremental FFS build should filter out paths based on mongo regex filters Key: OAK-10693 URL: https://issues.apache.org/jira/browse/OAK-10693 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta As part of https://issues.apache.org/jira/browse/OAK-10681 , support for custom filters was added to build the base FFS using pipelined approach. We need to add similar support for the incremental FFS builds as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10503) Incorrect operand in incremental FFS can lead to failure during merge step
[
https://issues.apache.org/jira/browse/OAK-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1675#comment-1675
]
Nitin Gupta edited comment on OAK-10503 at 10/25/23 5:11 AM:
-
trunk :
[https://github.com/apache/jackrabbit-oak/commit/e904e4594274f28fd7499ec1620648893b43d6b0]
, wasn't able to reproduce with a test case, but the fix of not throwing
exception is harmless and should work. Keeping this open to try and write the
reproducible test case as well.
Update - I think we can close this for now and revisit this once we can
reproduce this with a test case. For now the warnings should help us detect
more such cases without blocking building the incremental FFS.
was (Author: nitigup):
trunk :
[https://github.com/apache/jackrabbit-oak/commit/e904e4594274f28fd7499ec1620648893b43d6b0]
, wasn't able to reproduce with a test case, but the fix of not throwing
exception is harmless and should work. Keeping this open to try and write the
reproducible test case as well.
> Incorrect operand in incremental FFS can lead to failure during merge step
> --
>
> Key: OAK-10503
> URL: https://issues.apache.org/jira/browse/OAK-10503
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
>
> There could be a case where a node was moved/renamed which apparently results
> the incremental FFS to have 2 entries.
>
> For example,
> NodeA | \{"prop":"value"}
> renamed to NodeB | \{"prop":"value"}
>
> then the incremental FFS has entries -
> NodeA | \{"prop":"value"} | D
> NodeB | \{"prop":"value"} | M
>
> The second entry's operand should be A and not M.
> The above analysis is an assumption from some observations during some tests
> on a large repository.
> A more detailed test case needs to be written to investigate this further.
>
> But the impact of this is that merge for this inc store fails here
> [https://jira.corp.adobe.com/browse/GRANITE-48075#:~:text=https%3A//github.com/apache/jackrabbit%2Doak/blob/trunk/oak%2Drun%2Dcommons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/MergeIncrementalFlatFileStore.java%23L118]
> .
>
> A simple solution could be to treat modification same as addition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10503) Incorrect operand in incremental FFS can lead to failure during merge step
[
https://issues.apache.org/jira/browse/OAK-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta resolved OAK-10503.
---
Fix Version/s: 1.60.0
Resolution: Fixed
> Incorrect operand in incremental FFS can lead to failure during merge step
> --
>
> Key: OAK-10503
> URL: https://issues.apache.org/jira/browse/OAK-10503
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
> Fix For: 1.60.0
>
>
> There could be a case where a node was moved/renamed which apparently results
> the incremental FFS to have 2 entries.
>
> For example,
> NodeA | \{"prop":"value"}
> renamed to NodeB | \{"prop":"value"}
>
> then the incremental FFS has entries -
> NodeA | \{"prop":"value"} | D
> NodeB | \{"prop":"value"} | M
>
> The second entry's operand should be A and not M.
> The above analysis is an assumption from some observations during some tests
> on a large repository.
> A more detailed test case needs to be written to investigate this further.
>
> But the impact of this is that merge for this inc store fails here
> [https://jira.corp.adobe.com/browse/GRANITE-48075#:~:text=https%3A//github.com/apache/jackrabbit%2Doak/blob/trunk/oak%2Drun%2Dcommons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/MergeIncrementalFlatFileStore.java%23L118]
> .
>
> A simple solution could be to treat modification same as addition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10503) Incorrect operand in incremental FFS can lead to failure during merge step
[
https://issues.apache.org/jira/browse/OAK-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta reassigned OAK-10503:
-
Assignee: Nitin Gupta
> Incorrect operand in incremental FFS can lead to failure during merge step
> --
>
> Key: OAK-10503
> URL: https://issues.apache.org/jira/browse/OAK-10503
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
>
> There could be a case where a node was moved/renamed which apparently results
> the incremental FFS to have 2 entries.
>
> For example,
> NodeA | \{"prop":"value"}
> renamed to NodeB | \{"prop":"value"}
>
> then the incremental FFS has entries -
> NodeA | \{"prop":"value"} | D
> NodeB | \{"prop":"value"} | M
>
> The second entry's operand should be A and not M.
> The above analysis is an assumption from some observations during some tests
> on a large repository.
> A more detailed test case needs to be written to investigate this further.
>
> But the impact of this is that merge for this inc store fails here
> [https://jira.corp.adobe.com/browse/GRANITE-48075#:~:text=https%3A//github.com/apache/jackrabbit%2Doak/blob/trunk/oak%2Drun%2Dcommons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/MergeIncrementalFlatFileStore.java%23L118]
> .
>
> A simple solution could be to treat modification same as addition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10503) Incorrect operand in incremental FFS can lead to failure during merge step
[
https://issues.apache.org/jira/browse/OAK-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1675#comment-1675
]
Nitin Gupta commented on OAK-10503:
---
trunk :
[https://github.com/apache/jackrabbit-oak/commit/e904e4594274f28fd7499ec1620648893b43d6b0]
, wasn't able to reproduce with a test case, but the fix of not throwing
exception is harmless and should work. Keeping this open to try and write the
reproducible test case as well.
> Incorrect operand in incremental FFS can lead to failure during merge step
> --
>
> Key: OAK-10503
> URL: https://issues.apache.org/jira/browse/OAK-10503
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Nitin Gupta
>Priority: Major
>
> There could be a case where a node was moved/renamed which apparently results
> the incremental FFS to have 2 entries.
>
> For example,
> NodeA | \{"prop":"value"}
> renamed to NodeB | \{"prop":"value"}
>
> then the incremental FFS has entries -
> NodeA | \{"prop":"value"} | D
> NodeB | \{"prop":"value"} | M
>
> The second entry's operand should be A and not M.
> The above analysis is an assumption from some observations during some tests
> on a large repository.
> A more detailed test case needs to be written to investigate this further.
>
> But the impact of this is that merge for this inc store fails here
> [https://jira.corp.adobe.com/browse/GRANITE-48075#:~:text=https%3A//github.com/apache/jackrabbit%2Doak/blob/trunk/oak%2Drun%2Dcommons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/MergeIncrementalFlatFileStore.java%23L118]
> .
>
> A simple solution could be to treat modification same as addition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10503) Incorrect operand in incremental FFS can lead to failure during merge step
Nitin Gupta created OAK-10503:
-
Summary: Incorrect operand in incremental FFS can lead to failure
during merge step
Key: OAK-10503
URL: https://issues.apache.org/jira/browse/OAK-10503
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Nitin Gupta
There could be a case where a node was moved/renamed which apparently results
the incremental FFS to have 2 entries.
For example,
NodeA | \{"prop":"value"}
renamed to NodeB | \{"prop":"value"}
then the incremental FFS has entries -
NodeA | \{"prop":"value"} | D
NodeB | \{"prop":"value"} | M
The second entry's operand should be A and not M.
The above analysis is an assumption from some observations during some tests on
a large repository.
A more detailed test case needs to be written to investigate this further.
But the impact of this is that merge for this inc store fails here
[https://jira.corp.adobe.com/browse/GRANITE-48075#:~:text=https%3A//github.com/apache/jackrabbit%2Doak/blob/trunk/oak%2Drun%2Dcommons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/MergeIncrementalFlatFileStore.java%23L118]
.
A simple solution could be to treat modification same as addition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10497) Properties order in FFS can be different across runs
[ https://issues.apache.org/jira/browse/OAK-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17776117#comment-17776117 ] Nitin Gupta commented on OAK-10497: --- PR [https://github.com/apache/jackrabbit-oak/pull/1158] > Properties order in FFS can be different across runs > > > Key: OAK-10497 > URL: https://issues.apache.org/jira/browse/OAK-10497 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > While building the FFS, the order of the properties can be different for the > same node across different builds/runs. > > This does not have any impact on indexing, but in case there's a need for > verification across different strategies to compare if the FFS built is the > same - this sometimes lead to false failures. > > We should ensure a sorted order of the properties of every node in the FFS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10497) Properties order in FFS can be different across runs
[ https://issues.apache.org/jira/browse/OAK-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10497: - Assignee: Nitin Gupta > Properties order in FFS can be different across runs > > > Key: OAK-10497 > URL: https://issues.apache.org/jira/browse/OAK-10497 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > While building the FFS, the order of the properties can be different for the > same node across different builds/runs. > > This does not have any impact on indexing, but in case there's a need for > verification across different strategies to compare if the FFS built is the > same - this sometimes lead to false failures. > > We should ensure a sorted order of the properties of every node in the FFS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10497) Properties order in FFS can be different across runs
Nitin Gupta created OAK-10497: - Summary: Properties order in FFS can be different across runs Key: OAK-10497 URL: https://issues.apache.org/jira/browse/OAK-10497 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta While building the FFS, the order of the properties can be different for the same node across different builds/runs. This does not have any impact on indexing, but in case there's a need for verification across different strategies to compare if the FFS built is the same - this sometimes lead to false failures. We should ensure a sorted order of the properties of every node in the FFS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10458) Indexing job: Make LZ4 the default compression algorithm in OAK
[
https://issues.apache.org/jira/browse/OAK-10458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770460#comment-17770460
]
Nitin Gupta edited comment on OAK-10458 at 9/29/23 2:20 PM:
Seems like the compression is being read from system property here as well
[https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57]
and
[https://github.com/apache/jackrabbit-oak/blob/ad64ecbcfbe4f78354dfe6aaa93148e237034868/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/flatfile/FlatFileSplitter.java#L76]
here too. We would need to change the default here as well.
Might be best to move this out to some util class and use it from there in
different places.
IndexStoreUtils
([https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/indexstore/IndexStoreUtils.java])
might be a good candidate
However I see there that gzip has been set as default for naming conventions
for maintaining backward compat
{code:java}
/**
* This function by default uses GNU zip as compression algorithm for
backward compatibility.
*/
public static String getSortedStoreFileName(boolean compressionEnabled) {
return getSortedStoreFileName(compressionEnabled ? Compression.GZIP :
Compression.NONE);
}
{code}
Also maybe we can expose the default value so that it can be used by clients as
well.
was (Author: nitigup):
Seems like the compression is being read from system property here as well
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57
and
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57
here too. We would need to change the default here as well.
Might be best to move this out to some util class and use it from there in
different places.
IndexStoreUtils
(https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/indexstore/IndexStoreUtils.java)
might be a good candidate
However I see there that gzip has been set as default for naming conventions
for maintaining backward compat
{code:java}
/**
* This function by default uses GNU zip as compression algorithm for
backward compatibility.
*/
public static String getSortedStoreFileName(boolean compressionEnabled) {
return getSortedStoreFileName(compressionEnabled ? Compression.GZIP :
Compression.NONE);
}
{code}
Also maybe we can expose the default value so that it can be used by clients as
well.
> Indexing job: Make LZ4 the default compression algorithm in OAK
> ---
>
> Key: OAK-10458
> URL: https://issues.apache.org/jira/browse/OAK-10458
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Nuno Santos
>Priority: Minor
> Labels: Indexing
> Fix For: 1.58.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10458) Indexing job: Make LZ4 the default compression algorithm in OAK
[
https://issues.apache.org/jira/browse/OAK-10458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770460#comment-17770460
]
Nitin Gupta edited comment on OAK-10458 at 9/29/23 2:16 PM:
Seems like the compression is being read from system property here as well
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57
and
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57
here too. We would need to change the default here as well.
Might be best to move this out to some util class and use it from there in
different places.
IndexStoreUtils
(https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/indexstore/IndexStoreUtils.java)
might be a good candidate
However I see there that gzip has been set as default for naming conventions
for maintaining backward compat
{code:java}
/**
* This function by default uses GNU zip as compression algorithm for
backward compatibility.
*/
public static String getSortedStoreFileName(boolean compressionEnabled) {
return getSortedStoreFileName(compressionEnabled ? Compression.GZIP :
Compression.NONE);
}
{code}
Also maybe we can expose the default value so that it can be used by clients as
well.
was (Author: nitigup):
Seems like the compression is being read from system property here as well
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57
and
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57
here too. We would need to change the default here as well.
Might be best to move this out to some util class and use it from there in
different places. Also maybe we can expose the default value so that it can be
used by clients as well.
> Indexing job: Make LZ4 the default compression algorithm in OAK
> ---
>
> Key: OAK-10458
> URL: https://issues.apache.org/jira/browse/OAK-10458
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Nuno Santos
>Priority: Minor
> Labels: Indexing
> Fix For: 1.58.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10458) Indexing job: Make LZ4 the default compression algorithm in OAK
[ https://issues.apache.org/jira/browse/OAK-10458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770460#comment-17770460 ] Nitin Gupta commented on OAK-10458: --- Seems like the compression is being read from system property here as well https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57 and https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run-commons/src/main/java/org/apache/jackrabbit/oak/index/indexer/document/incrementalstore/IncrementalStoreBuilder.java#L57 here too. We would need to change the default here as well. Might be best to move this out to some util class and use it from there in different places. Also maybe we can expose the default value so that it can be used by clients as well. > Indexing job: Make LZ4 the default compression algorithm in OAK > --- > > Key: OAK-10458 > URL: https://issues.apache.org/jira/browse/OAK-10458 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Minor > Labels: Indexing > Fix For: 1.58.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (OAK-10458) Indexing job: Make LZ4 the default compression algorithm in OAK
[ https://issues.apache.org/jira/browse/OAK-10458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reopened OAK-10458: --- > Indexing job: Make LZ4 the default compression algorithm in OAK > --- > > Key: OAK-10458 > URL: https://issues.apache.org/jira/browse/OAK-10458 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Nuno Santos >Priority: Minor > Labels: Indexing > Fix For: 1.58.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10457) Add support to filter and sort a given FFS based provided with predicates and preffered paths
Nitin Gupta created OAK-10457: - Summary: Add support to filter and sort a given FFS based provided with predicates and preffered paths Key: OAK-10457 URL: https://issues.apache.org/jira/browse/OAK-10457 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta Given a base FFS on root / , which is only sorted by path without considering preferredPathElements, and a set of preferredPathElements and a predicate based on include/exclude paths, produce a new FFS that is filtered and sorted based on the provided predicate and preferred path. Also write a test to verify an FFS produced this was is exactly similar to one produced by normal FFS creation process that picks the preferredPathElements and predicates from the index definition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10442) Lucene Index - node type inheritance is not properly working for aggregation
[ https://issues.apache.org/jira/browse/OAK-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765534#comment-17765534 ] Nitin Gupta commented on OAK-10442: --- trunk : https://github.com/apache/jackrabbit-oak/commit/33dbf0b8b9b6fd702cf3b0b1ca1bae32c6c6f2f7 > Lucene Index - node type inheritance is not properly working for aggregation > > > Key: OAK-10442 > URL: https://issues.apache.org/jira/browse/OAK-10442 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10442) Lucene Index - node type inheritance is not properly working for aggregation
[ https://issues.apache.org/jira/browse/OAK-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10442. --- Fix Version/s: 1.58.0 Resolution: Fixed > Lucene Index - node type inheritance is not properly working for aggregation > > > Key: OAK-10442 > URL: https://issues.apache.org/jira/browse/OAK-10442 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.58.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10442) Lucene Index - node type inheritance is not properly working for aggregation
[ https://issues.apache.org/jira/browse/OAK-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764990#comment-17764990 ] Nitin Gupta commented on OAK-10442: --- I think this is not a bug but something that has never been implemented. As per the oak docs, I see it's mentioned for indexing rules explicitly that they handle node type inheritance, and I see the handling in code as well. But for Aggregation, I don't see anywhere in the docs about node type inheritance. Seems like we never supported it. For now made a change in the doc to explicitly reflect that this is not supported - https://github.com/apache/jackrabbit-oak/pull/1118 > Lucene Index - node type inheritance is not properly working for aggregation > > > Key: OAK-10442 > URL: https://issues.apache.org/jira/browse/OAK-10442 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10442) Lucene Index - node type inheritance is not properly working for aggregation
[ https://issues.apache.org/jira/browse/OAK-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10442: - Assignee: Nitin Gupta > Lucene Index - node type inheritance is not properly working for aggregation > > > Key: OAK-10442 > URL: https://issues.apache.org/jira/browse/OAK-10442 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10442) Lucene Index - node type inheritance is not properly working for aggregation
Nitin Gupta created OAK-10442: - Summary: Lucene Index - node type inheritance is not properly working for aggregation Key: OAK-10442 URL: https://issues.apache.org/jira/browse/OAK-10442 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10433) Throttle excessive warning log messages when reindexing environments with non-fatal issues in index definition
[ https://issues.apache.org/jira/browse/OAK-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10433: - Assignee: Nitin Gupta > Throttle excessive warning log messages when reindexing environments with > non-fatal issues in index definition > -- > > Key: OAK-10433 > URL: https://issues.apache.org/jira/browse/OAK-10433 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.58.0 > > > Warn logs like - > [/oak:index/testIndex] Ignoring ordered property testProp of type STRINGS for > path /a/b/c as multivalued ordered property not supported > can flood the loggers. Frequency of printing these logs should be throttled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10433) Throttle excessive warning log messages when reindexing environments with non-fatal issues in index definition
[ https://issues.apache.org/jira/browse/OAK-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10433. --- Fix Version/s: 1.58.0 Resolution: Fixed > Throttle excessive warning log messages when reindexing environments with > non-fatal issues in index definition > -- > > Key: OAK-10433 > URL: https://issues.apache.org/jira/browse/OAK-10433 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Priority: Major > Fix For: 1.58.0 > > > Warn logs like - > [/oak:index/testIndex] Ignoring ordered property testProp of type STRINGS for > path /a/b/c as multivalued ordered property not supported > can flood the loggers. Frequency of printing these logs should be throttled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10433) Throttle excessive warning log messages when reindexing environments with non-fatal issues in index definition
[ https://issues.apache.org/jira/browse/OAK-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763128#comment-17763128 ] Nitin Gupta commented on OAK-10433: --- trunk : https://github.com/apache/jackrabbit-oak/commit/70c4eb84c5d6202f4b7686b9a93d50b041df1f33 > Throttle excessive warning log messages when reindexing environments with > non-fatal issues in index definition > -- > > Key: OAK-10433 > URL: https://issues.apache.org/jira/browse/OAK-10433 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Priority: Major > > Warn logs like - > [/oak:index/testIndex] Ignoring ordered property testProp of type STRINGS for > path /a/b/c as multivalued ordered property not supported > can flood the loggers. Frequency of printing these logs should be throttled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10433) Throttle excessive warning log messages when reindexing environments with non-fatal issues in index definition
[ https://issues.apache.org/jira/browse/OAK-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta updated OAK-10433: -- Description: Warn logs like - [/oak:index/testIndex] Ignoring ordered property testProp of type STRINGS for path /a/b/c as multivalued ordered property not supported can flood the loggers. Frequency of printing these logs should be throttled. > Throttle excessive warning log messages when reindexing environments with > non-fatal issues in index definition > -- > > Key: OAK-10433 > URL: https://issues.apache.org/jira/browse/OAK-10433 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Priority: Major > > Warn logs like - > [/oak:index/testIndex] Ignoring ordered property testProp of type STRINGS for > path /a/b/c as multivalued ordered property not supported > can flood the loggers. Frequency of printing these logs should be throttled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10433) Throttle excessive warning log messages when reindexing environments with non-fatal issues in index definition
[ https://issues.apache.org/jira/browse/OAK-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta updated OAK-10433: -- Environment: (was: Warn logs like - [/oak:index/testIndex] Ignoring ordered property testProp of type STRINGS for path /a/b/c as multivalued ordered property not supported can flood the loggers. Frequency of printing these logs should be throttled.) > Throttle excessive warning log messages when reindexing environments with > non-fatal issues in index definition > -- > > Key: OAK-10433 > URL: https://issues.apache.org/jira/browse/OAK-10433 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10433) Throttle excessive warning log messages when reindexing environments with non-fatal issues in index definition
Nitin Gupta created OAK-10433: - Summary: Throttle excessive warning log messages when reindexing environments with non-fatal issues in index definition Key: OAK-10433 URL: https://issues.apache.org/jira/browse/OAK-10433 Project: Jackrabbit Oak Issue Type: Task Environment: Warn logs like - [/oak:index/testIndex] Ignoring ordered property testProp of type STRINGS for path /a/b/c as multivalued ordered property not supported can flood the loggers. Frequency of printing these logs should be throttled. Reporter: Nitin Gupta -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10265) Oak-run offline reindex - async lane revert not taking place for stored index def after index import
[ https://issues.apache.org/jira/browse/OAK-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10265. --- Fix Version/s: 1.54.0 Resolution: Fixed > Oak-run offline reindex - async lane revert not taking place for stored index > def after index import > > > Key: OAK-10265 > URL: https://issues.apache.org/jira/browse/OAK-10265 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.54.0 > > > During offline reindex using oak-run, > the index import phase first changes the async property to temp-async and > keeps the original value in async-previous property. > This is reverted when the import is done. However it appears that the revert > doesn't happen for the stored index definition and leaves that at > async = temp-async > async-previous = [async, nrt] > We should probably add refresh=true to avoid this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10265) Oak-run offline reindex - async lane revert not taking place for stored index def after index import
[ https://issues.apache.org/jira/browse/OAK-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728298#comment-17728298 ] Nitin Gupta commented on OAK-10265: --- trunk - https://github.com/apache/jackrabbit-oak/commit/846fcb4e89055504cb5b340462b1a961bfb0019d > Oak-run offline reindex - async lane revert not taking place for stored index > def after index import > > > Key: OAK-10265 > URL: https://issues.apache.org/jira/browse/OAK-10265 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > During offline reindex using oak-run, > the index import phase first changes the async property to temp-async and > keeps the original value in async-previous property. > This is reverted when the import is done. However it appears that the revert > doesn't happen for the stored index definition and leaves that at > async = temp-async > async-previous = [async, nrt] > We should probably add refresh=true to avoid this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10265) Oak-run offline reindex - async lane revert not taking place for stored index def after index import
[ https://issues.apache.org/jira/browse/OAK-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10265: - Assignee: Nitin Gupta > Oak-run offline reindex - async lane revert not taking place for stored index > def after index import > > > Key: OAK-10265 > URL: https://issues.apache.org/jira/browse/OAK-10265 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > During offline reindex using oak-run, > the index import phase first changes the async property to temp-async and > keeps the original value in async-previous property. > This is reverted when the import is done. However it appears that the revert > doesn't happen for the stored index definition and leaves that at > async = temp-async > async-previous = [async, nrt] > We should probably add refresh=true to avoid this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10265) Oak-run offline reindex - async lane revert not taking place for stored index def after index import
Nitin Gupta created OAK-10265: - Summary: Oak-run offline reindex - async lane revert not taking place for stored index def after index import Key: OAK-10265 URL: https://issues.apache.org/jira/browse/OAK-10265 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta During offline reindex using oak-run, the index import phase first changes the async property to temp-async and keeps the original value in async-previous property. This is reverted when the import is done. However it appears that the revert doesn't happen for the stored index definition and leaves that at async = temp-async async-previous = [async, nrt] We should probably add refresh=true to avoid this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10150) Add a test for index purge command where the latest OOB index is disabled and the queries are served by a lower versioned index
[ https://issues.apache.org/jira/browse/OAK-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10150. --- Fix Version/s: 1.52.0 Resolution: Fixed > Add a test for index purge command where the latest OOB index is disabled and > the queries are served by a lower versioned index > --- > > Key: OAK-10150 > URL: https://issues.apache.org/jira/browse/OAK-10150 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.52.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10150) Add a test for index purge command where the latest OOB index is disabled and the queries are served by a lower versioned index
[ https://issues.apache.org/jira/browse/OAK-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703453#comment-17703453 ] Nitin Gupta commented on OAK-10150: --- https://github.com/apache/jackrabbit-oak/commit/0720de7083d6c5ba40a7912af8f4da900410e133 > Add a test for index purge command where the latest OOB index is disabled and > the queries are served by a lower versioned index > --- > > Key: OAK-10150 > URL: https://issues.apache.org/jira/browse/OAK-10150 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10150) Add a test for index purge command where the latest OOB index is disabled and the queries are served by a lower versioned index
[ https://issues.apache.org/jira/browse/OAK-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10150: - Assignee: Nitin Gupta > Add a test for index purge command where the latest OOB index is disabled and > the queries are served by a lower versioned index > --- > > Key: OAK-10150 > URL: https://issues.apache.org/jira/browse/OAK-10150 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10150) Add a test for index purge command where the latest OOB index is disabled and the queries are served by a lower versioned index
[ https://issues.apache.org/jira/browse/OAK-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703127#comment-17703127 ] Nitin Gupta commented on OAK-10150: --- PR https://github.com/apache/jackrabbit-oak/pull/875/files > Add a test for index purge command where the latest OOB index is disabled and > the queries are served by a lower versioned index > --- > > Key: OAK-10150 > URL: https://issues.apache.org/jira/browse/OAK-10150 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10150) Add a test for index purge command where the latest OOB index is disabled and the queries are served by a lower versioned index
Nitin Gupta created OAK-10150: - Summary: Add a test for index purge command where the latest OOB index is disabled and the queries are served by a lower versioned index Key: OAK-10150 URL: https://issues.apache.org/jira/browse/OAK-10150 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10098) Oak Run - PurgeOldIndexVersion - Add support to auto purge ES indexes and delete remote ES indexes as well
[ https://issues.apache.org/jira/browse/OAK-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta updated OAK-10098: -- Summary: Oak Run - PurgeOldIndexVersion - Add support to auto purge ES indexes and delete remote ES indexes as well (was: PurgeOldIndexVersion in oak run should delete ES indexes created on elasticsearch when deleting the index from oak) > Oak Run - PurgeOldIndexVersion - Add support to auto purge ES indexes and > delete remote ES indexes as well > -- > > Key: OAK-10098 > URL: https://issues.apache.org/jira/browse/OAK-10098 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.50.0 > > > PurgeOldIndexVersion deletes the oak indexes that are obsolete. But in case > of ES this leaves behind dangling indexes on the ES server. > PurgeOldIndexVersion should handle this deletion as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10098) PurgeOldIndexVersion in oak run should delete ES indexes created on elasticsearch when deleting the index from oak
[ https://issues.apache.org/jira/browse/OAK-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10098. --- Fix Version/s: 1.50.0 Resolution: Fixed > PurgeOldIndexVersion in oak run should delete ES indexes created on > elasticsearch when deleting the index from oak > -- > > Key: OAK-10098 > URL: https://issues.apache.org/jira/browse/OAK-10098 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.50.0 > > > PurgeOldIndexVersion deletes the oak indexes that are obsolete. But in case > of ES this leaves behind dangling indexes on the ES server. > PurgeOldIndexVersion should handle this deletion as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10098) PurgeOldIndexVersion in oak run should delete ES indexes created on elasticsearch when deleting the index from oak
[ https://issues.apache.org/jira/browse/OAK-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699592#comment-17699592 ] Nitin Gupta commented on OAK-10098: --- trunk : https://github.com/apache/jackrabbit-oak/commit/6ba37c2dee48034b37b30bbcbff7ffbf2f4d657a > PurgeOldIndexVersion in oak run should delete ES indexes created on > elasticsearch when deleting the index from oak > -- > > Key: OAK-10098 > URL: https://issues.apache.org/jira/browse/OAK-10098 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > PurgeOldIndexVersion deletes the oak indexes that are obsolete. But in case > of ES this leaves behind dangling indexes on the ES server. > PurgeOldIndexVersion should handle this deletion as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10137) Static variable referenced from a non-static context
[ https://issues.apache.org/jira/browse/OAK-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698698#comment-17698698 ] Nitin Gupta commented on OAK-10137: --- trunk: https://github.com/apache/jackrabbit-oak/commit/431c8dcaa380e18c1ae678212f1757d233f4639a > Static variable referenced from a non-static context > > > Key: OAK-10137 > URL: https://issues.apache.org/jira/browse/OAK-10137 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > https://github.com/apache/jackrabbit-oak/blame/trunk/oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java#L188 > waitForESAcknowledgement is a static variable which is accessed from a > non-static context. It is set to true only at initialization, in a static > context. So if at some point it is set to false, it will never again become > true during the runtime of the JVM. And the BuikProcessor instance is not > static, so there may be many instances created in the same JVM execution -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10137) Static variable referenced from a non-static context
[ https://issues.apache.org/jira/browse/OAK-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10137. --- Fix Version/s: 1.50.0 Resolution: Fixed > Static variable referenced from a non-static context > > > Key: OAK-10137 > URL: https://issues.apache.org/jira/browse/OAK-10137 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.50.0 > > > https://github.com/apache/jackrabbit-oak/blame/trunk/oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java#L188 > waitForESAcknowledgement is a static variable which is accessed from a > non-static context. It is set to true only at initialization, in a static > context. So if at some point it is set to false, it will never again become > true during the runtime of the JVM. And the BuikProcessor instance is not > static, so there may be many instances created in the same JVM execution -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10137) Static variable referenced from a non-static context
[ https://issues.apache.org/jira/browse/OAK-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698447#comment-17698447 ] Nitin Gupta commented on OAK-10137: --- PR - https://github.com/apache/jackrabbit-oak/pull/870/files > Static variable referenced from a non-static context > > > Key: OAK-10137 > URL: https://issues.apache.org/jira/browse/OAK-10137 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > https://github.com/apache/jackrabbit-oak/blame/trunk/oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java#L188 > waitForESAcknowledgement is a static variable which is accessed from a > non-static context. It is set to true only at initialization, in a static > context. So if at some point it is set to false, it will never again become > true during the runtime of the JVM. And the BuikProcessor instance is not > static, so there may be many instances created in the same JVM execution -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10137) Static variable referenced from a non-static context
[ https://issues.apache.org/jira/browse/OAK-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10137: - Assignee: Nitin Gupta > Static variable referenced from a non-static context > > > Key: OAK-10137 > URL: https://issues.apache.org/jira/browse/OAK-10137 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > https://github.com/apache/jackrabbit-oak/blame/trunk/oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java#L188 > waitForESAcknowledgement is a static variable which is accessed from a > non-static context. It is set to true only at initialization, in a static > context. So if at some point it is set to false, it will never again become > true during the runtime of the JVM. And the BuikProcessor instance is not > static, so there may be many instances created in the same JVM execution -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10137) Static variable referenced from a non-static context
Nitin Gupta created OAK-10137: - Summary: Static variable referenced from a non-static context Key: OAK-10137 URL: https://issues.apache.org/jira/browse/OAK-10137 Project: Jackrabbit Oak Issue Type: Bug Reporter: Nitin Gupta https://github.com/apache/jackrabbit-oak/blame/trunk/oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java#L188 waitForESAcknowledgement is a static variable which is accessed from a non-static context. It is set to true only at initialization, in a static context. So if at some point it is set to false, it will never again become true during the runtime of the JVM. And the BuikProcessor instance is not static, so there may be many instances created in the same JVM execution -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10098) PurgeOldIndexVersion in oak run should delete ES indexes created on elasticsearch when deleting the index from oak
Nitin Gupta created OAK-10098: - Summary: PurgeOldIndexVersion in oak run should delete ES indexes created on elasticsearch when deleting the index from oak Key: OAK-10098 URL: https://issues.apache.org/jira/browse/OAK-10098 Project: Jackrabbit Oak Issue Type: Task Reporter: Nitin Gupta PurgeOldIndexVersion deletes the oak indexes that are obsolete. But in case of ES this leaves behind dangling indexes on the ES server. PurgeOldIndexVersion should handle this deletion as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10098) PurgeOldIndexVersion in oak run should delete ES indexes created on elasticsearch when deleting the index from oak
[ https://issues.apache.org/jira/browse/OAK-10098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10098: - Assignee: Nitin Gupta > PurgeOldIndexVersion in oak run should delete ES indexes created on > elasticsearch when deleting the index from oak > -- > > Key: OAK-10098 > URL: https://issues.apache.org/jira/browse/OAK-10098 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > PurgeOldIndexVersion deletes the oak indexes that are obsolete. But in case > of ES this leaves behind dangling indexes on the ES server. > PurgeOldIndexVersion should handle this deletion as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10095) NullPointerException in FieldFactory.dateToLong
[
https://issues.apache.org/jira/browse/OAK-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682813#comment-17682813
]
Nitin Gupta commented on OAK-10095:
---
trunk :
https://github.com/apache/jackrabbit-oak/commit/5671cdce1d1f9dce48546ef27818153f89d2e9bd
> NullPointerException in FieldFactory.dateToLong
> ---
>
> Key: OAK-10095
> URL: https://issues.apache.org/jira/browse/OAK-10095
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
>
> We have the following warning in the log file, with a NullPointerException.
> The NPE should not occur in this case. It doesn't seem to cause very big
> issue, but it seems to confuse people and then we have to investigate into
> the issue maybe because of that.
> {noformat}
> jcr:content/metadata/... of type LONG to type DATE for path /content/...
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.FieldFactory.dateToLong(FieldFactory.java:189)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:282)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:55)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.addTypedOrderedFields(FulltextDocumentMaker.java:384)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.access$100(FulltextDocumentMaker.java:58)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10095) NullPointerException in FieldFactory.dateToLong
[
https://issues.apache.org/jira/browse/OAK-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta resolved OAK-10095.
---
Fix Version/s: 1.50.0
Resolution: Fixed
> NullPointerException in FieldFactory.dateToLong
> ---
>
> Key: OAK-10095
> URL: https://issues.apache.org/jira/browse/OAK-10095
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
> Fix For: 1.50.0
>
>
> We have the following warning in the log file, with a NullPointerException.
> The NPE should not occur in this case. It doesn't seem to cause very big
> issue, but it seems to confuse people and then we have to investigate into
> the issue maybe because of that.
> {noformat}
> jcr:content/metadata/... of type LONG to type DATE for path /content/...
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.FieldFactory.dateToLong(FieldFactory.java:189)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:282)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:55)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.addTypedOrderedFields(FulltextDocumentMaker.java:384)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.access$100(FulltextDocumentMaker.java:58)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (OAK-10001) Bump up minimal Java version to 11
[ https://issues.apache.org/jira/browse/OAK-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681411#comment-17681411 ] Nitin Gupta edited comment on OAK-10001 at 1/31/23 9:56 AM: trunk: [caf43a19c5|https://github.com/apache/jackrabbit-oak/commit/caf43a19c505bb02afa237153c55d68c2630817f] trunk : [e156ced2c1|https://github.com/apache/jackrabbit-oak/commit/e156ced2c178b81ff0da98672029d76f2e252cad] (Update jenkinsfile to use j11 based nodes) was (Author: reschke): trunk: [caf43a19c5|https://github.com/apache/jackrabbit-oak/commit/caf43a19c505bb02afa237153c55d68c2630817f] > Bump up minimal Java version to 11 > -- > > Key: OAK-10001 > URL: https://issues.apache.org/jira/browse/OAK-10001 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.50.0 > > > Active support for Java 8 ended a few months ago (see > [https://endoflife.date/java]). > Java 11 has been available for four years, and offers various improvements > (in particular, it contains extensions that may help in avoiding use of Guava > (see OAK-7182)). > (Note that even Java 11 will be out of active support in a few months - so a > subsequent update to the next LTS release - Java 17 - is not that far away). > Potential downsides: > - backports to 1.22 might become harder (1.8 will be EOLd next spring > anyway). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10095) NullPointerException in FieldFactory.dateToLong
[
https://issues.apache.org/jira/browse/OAK-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682418#comment-17682418
]
Nitin Gupta commented on OAK-10095:
---
[https://github.com/apache/jackrabbit-oak/pull/838/files]
> NullPointerException in FieldFactory.dateToLong
> ---
>
> Key: OAK-10095
> URL: https://issues.apache.org/jira/browse/OAK-10095
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
>
> We have the following warning in the log file, with a NullPointerException.
> The NPE should not occur in this case. It doesn't seem to cause very big
> issue, but it seems to confuse people and then we have to investigate into
> the issue maybe because of that.
> {noformat}
> jcr:content/metadata/... of type LONG to type DATE for path /content/...
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.FieldFactory.dateToLong(FieldFactory.java:189)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:282)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:55)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.addTypedOrderedFields(FulltextDocumentMaker.java:384)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.access$100(FulltextDocumentMaker.java:58)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10095) NullPointerException in FieldFactory.dateToLong
[
https://issues.apache.org/jira/browse/OAK-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta reassigned OAK-10095:
-
Assignee: Nitin Gupta
> NullPointerException in FieldFactory.dateToLong
> ---
>
> Key: OAK-10095
> URL: https://issues.apache.org/jira/browse/OAK-10095
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Nitin Gupta
>Assignee: Nitin Gupta
>Priority: Major
>
> We have the following warning in the log file, with a NullPointerException.
> The NPE should not occur in this case. It doesn't seem to cause very big
> issue, but it seems to confuse people and then we have to investigate into
> the issue maybe because of that.
> {noformat}
> jcr:content/metadata/... of type LONG to type DATE for path /content/...
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.FieldFactory.dateToLong(FieldFactory.java:189)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:282)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:55)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.addTypedOrderedFields(FulltextDocumentMaker.java:384)
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.access$100(FulltextDocumentMaker.java:58)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10095) NullPointerException in FieldFactory.dateToLong
Nitin Gupta created OAK-10095:
-
Summary: NullPointerException in FieldFactory.dateToLong
Key: OAK-10095
URL: https://issues.apache.org/jira/browse/OAK-10095
Project: Jackrabbit Oak
Issue Type: Bug
Reporter: Nitin Gupta
We have the following warning in the log file, with a NullPointerException. The
NPE should not occur in this case. It doesn't seem to cause very big issue, but
it seems to confuse people and then we have to investigate into the issue maybe
because of that.
{noformat}
jcr:content/metadata/... of type LONG to type DATE for path /content/...
java.lang.NullPointerException: null
at
org.apache.jackrabbit.oak.plugins.index.lucene.FieldFactory.dateToLong(FieldFactory.java:189)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:282)
at
org.apache.jackrabbit.oak.plugins.index.lucene.LuceneDocumentMaker.indexTypeOrderedFields(LuceneDocumentMaker.java:55)
at
org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.addTypedOrderedFields(FulltextDocumentMaker.java:384)
at
org.apache.jackrabbit.oak.plugins.index.search.spi.editor.FulltextDocumentMaker.access$100(FulltextDocumentMaker.java:58)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (OAK-9980) Index Purging Logic fails when trying to delete :oak:mount-libs* (read-only) node under index definition for composite nodestore
[ https://issues.apache.org/jira/browse/OAK-9980 ] Nitin Gupta deleted comment on OAK-9980: -- was (Author: nitigup): [https://github.com/apache/jackrabbit-oak/commit/0b6dfc995e3d278865c87242bb91898862f50556] > Index Purging Logic fails when trying to delete :oak:mount-libs* (read-only) > node under index definition for composite nodestore > > > Key: OAK-9980 > URL: https://issues.apache.org/jira/browse/OAK-9980 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-9980) Index Purging Logic fails when trying to delete :oak:mount-libs* (read-only) node under index definition for composite nodestore
[ https://issues.apache.org/jira/browse/OAK-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681878#comment-17681878 ] Nitin Gupta commented on OAK-9980: -- [https://github.com/apache/jackrabbit-oak/commit/0b6dfc995e3d278865c87242bb91898862f50556] > Index Purging Logic fails when trying to delete :oak:mount-libs* (read-only) > node under index definition for composite nodestore > > > Key: OAK-9980 > URL: https://issues.apache.org/jira/browse/OAK-9980 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10033) Conditions on dates use the wrong range
[
https://issues.apache.org/jira/browse/OAK-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678289#comment-17678289
]
Nitin Gupta commented on OAK-10033:
---
trunk :
[https://github.com/apache/jackrabbit-oak/commit/9d91389b6eaf1a0bb790204643b2ce03531fe624]
> Conditions on dates use the wrong range
> ---
>
> Key: OAK-10033
> URL: https://issues.apache.org/jira/browse/OAK-10033
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Mohit Kataria
>Assignee: Mohit Kataria
>Priority: Major
> Fix For: 1.48.0
>
>
> For queries like:
> SELECT * FROM [nt:base] AS main WHERE (main.[startTime] <>
> cast('1971-01-01T13:00:00.000Z' AS date))
> The condition uses the wrong range, as negative values are possible. The
> range should be -9223372036854775808 TO 9223372036854775807 and not 0 TO
> 9223372036854775807.
> {code:java}
> [calendar@startTime] <> cast('1971-01-01T13:00:00.000Z' AS date)
> +calendar@startTime:[0 TO 9223372036854775807]
> -calendar@startTime:[3158280 TO 3158280]{code}
> Source code:
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/PropertyValueImpl.java]
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1227]
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, 0L, Long.MAX_VALUE, true,
> true);{code}
> This isn't correct, as 0 means 1970-01-01T00:00:00.000Z
> It should probably be :
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, Long.MIN_VALUE,
> Long.MAX_VALUE, true, true);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10033) Conditions on dates use the wrong range
[
https://issues.apache.org/jira/browse/OAK-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta resolved OAK-10033.
---
Resolution: Fixed
> Conditions on dates use the wrong range
> ---
>
> Key: OAK-10033
> URL: https://issues.apache.org/jira/browse/OAK-10033
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Mohit Kataria
>Assignee: Mohit Kataria
>Priority: Major
> Fix For: 1.48.0
>
>
> For queries like:
> SELECT * FROM [nt:base] AS main WHERE (main.[startTime] <>
> cast('1971-01-01T13:00:00.000Z' AS date))
> The condition uses the wrong range, as negative values are possible. The
> range should be -9223372036854775808 TO 9223372036854775807 and not 0 TO
> 9223372036854775807.
> {code:java}
> [calendar@startTime] <> cast('1971-01-01T13:00:00.000Z' AS date)
> +calendar@startTime:[0 TO 9223372036854775807]
> -calendar@startTime:[3158280 TO 3158280]{code}
> Source code:
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/ast/PropertyValueImpl.java]
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java#L1227]
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, 0L, Long.MAX_VALUE, true,
> true);{code}
> This isn't correct, as 0 means 1970-01-01T00:00:00.000Z
> It should probably be :
> {code:java}
> // not null. For date lower bound of zero can be used
> return NumericRangeQuery.newLongRange(propertyName, Long.MIN_VALUE,
> Long.MAX_VALUE, true, true);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10063) AsyncIndexUpdate - Logger not printing complete message
[ https://issues.apache.org/jira/browse/OAK-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta resolved OAK-10063. --- Fix Version/s: 1.48.0 Resolution: Fixed > AsyncIndexUpdate - Logger not printing complete message > --- > > Key: OAK-10063 > URL: https://issues.apache.org/jira/browse/OAK-10063 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > Fix For: 1.48.0 > > > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/AsyncIndexUpdate.java#L1099] > > > This here doesn't print the e.getMessage() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10063) AsyncIndexUpdate - Logger not printing complete message
[ https://issues.apache.org/jira/browse/OAK-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta reassigned OAK-10063: - Assignee: Nitin Gupta > AsyncIndexUpdate - Logger not printing complete message > --- > > Key: OAK-10063 > URL: https://issues.apache.org/jira/browse/OAK-10063 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Nitin Gupta >Assignee: Nitin Gupta >Priority: Major > > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/AsyncIndexUpdate.java#L1099] > > > This here doesn't print the e.getMessage() -- This message was sent by Atlassian Jira (v8.20.10#820010)
