[jira] [Updated] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[ https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8703: - Summary: Configure the maximum number of revisions to be checked by consistency check (was: Configure the maximum number of revisions to be checked by Consistency ) > Configure the maximum number of revisions to be checked by consistency check > > > Key: OAK-8703 > URL: https://issues.apache.org/jira/browse/OAK-8703 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Ieran Draghiciu >Priority: Major > Labels: oak-run > > Add the ability to configure the maximum number of request to be verify by > the ConsistencyChecker -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[ https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8703: - Component/s: oak-run > Configure the maximum number of revisions to be checked by consistency check > > > Key: OAK-8703 > URL: https://issues.apache.org/jira/browse/OAK-8703 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: oak-run, segment-tar >Reporter: Ieran Draghiciu >Priority: Major > Labels: oak-run > > Add the ability to configure the maximum number of request to be verify by > the ConsistencyChecker -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[ https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8703: - Component/s: segment-tar > Configure the maximum number of revisions to be checked by consistency check > > > Key: OAK-8703 > URL: https://issues.apache.org/jira/browse/OAK-8703 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Ieran Draghiciu >Priority: Major > Labels: oak-run > > Add the ability to configure the maximum number of request to be verify by > the ConsistencyChecker -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[ https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8703: - Labels: (was: oak-run) > Configure the maximum number of revisions to be checked by consistency check > > > Key: OAK-8703 > URL: https://issues.apache.org/jira/browse/OAK-8703 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: oak-run, segment-tar >Reporter: Ieran Draghiciu >Priority: Major > > Add the ability to configure the maximum number of request to be verify by > the ConsistencyChecker -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[ https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-8703: Assignee: Andrei Dulceanu > Configure the maximum number of revisions to be checked by consistency check > > > Key: OAK-8703 > URL: https://issues.apache.org/jira/browse/OAK-8703 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: oak-run, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > > Add the ability to configure the maximum number of request to be verify by > the ConsistencyChecker -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[ https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955933#comment-16955933 ] Andrei Dulceanu commented on OAK-8703: -- [~ierandra], can you please update the documentation [0] with this change? [0] [https://jackrabbit.apache.org/oak/docs/nodestore/segment/overview.html#check] > Configure the maximum number of revisions to be checked by consistency check > > > Key: OAK-8703 > URL: https://issues.apache.org/jira/browse/OAK-8703 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: oak-run, segment-tar >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8703.patch > > > Add the ability to configure the maximum number of request to be verify by > the ConsistencyChecker -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[
https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8703:
-
Description: We need the ability to configure the maximum number of
revisions to be checked by the ConsistencyChecker. For this we are adding a
new argument {{--maxRevisionsToCheck}} (with default value 1). (was: We need
the ability to configure the maximum number of request to be verify by the
ConsistencyChecker. For this we are adding a new argument
{{--maxRevisionsToCheck}} (with default value 1).
Documentation changes:
{code:java}
The check tool inspects an existing Segment Store at PATH for eventual
inconsistencies. The algorithm implemented by this tool traverses the last
revision in the journal. The actual nodes and properties are traversed,
verifying that every piece of data is reachable and undamaged. If more then 1
revision must be verified, --maxRevisionsToCheck option can be used. Moreover,
if --head and --checkpoints options are used, the scope of the traversal can be
limited to head state and/or a subset of checkpoints. A deep scan of the
content tree, traversing every node and every property will be performed by
default. The default scope includes head state and all checkpoints.
The optional --maxRevisionsToCheck [Integer] argument can be used to control
the maximum number of revisions to be verified. Default value is 1. If the
first revision is not consistent configure the argument to 2. This will verify
the last 2 revisions. However if the first revision is consistent the
verification of the second revision is skipped.
{code})
> Configure the maximum number of revisions to be checked by consistency check
>
>
> Key: OAK-8703
> URL: https://issues.apache.org/jira/browse/OAK-8703
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: oak-run, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8703-02.patch, OAK-8703.patch
>
>
> We need the ability to configure the maximum number of revisions to be
> checked by the ConsistencyChecker. For this we are adding a new argument
> {{--maxRevisionsToCheck}} (with default value 1).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[
https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8703:
-
Description:
We need the ability to configure the maximum number of revisions to be checked
by {{oak-run check}}.
For this we are adding a new argument {{--maxRevisionsToCheck}} (with default
value 1).
was:We need the ability to configure the maximum number of revisions to be
checked by the ConsistencyChecker. For this we are adding a new argument
{{--maxRevisionsToCheck}} (with default value 1).
> Configure the maximum number of revisions to be checked by consistency check
>
>
> Key: OAK-8703
> URL: https://issues.apache.org/jira/browse/OAK-8703
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: oak-run, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8703-02.patch, OAK-8703.patch
>
>
> We need the ability to configure the maximum number of revisions to be
> checked by {{oak-run check}}.
> For this we are adding a new argument {{--maxRevisionsToCheck}} (with default
> value 1).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[
https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8703:
-
Description:
We need the ability to configure the maximum number of revisions to be checked
by {{oak-run check}}. This way we can quickly tell whether there's a valid
revision in the last {{n}} revisions. Moreover, this comes handy when we want
to test only the last revision (current head state) of the repository.
For this we can add a new optional argument {{--maxRevisionsToCheck}}. If the
argument is used, but a specific number of revisions is not specified, the tool
will check by default only the last revision.
was:
We need the ability to configure the maximum number of revisions to be checked
by {{oak-run check}}.
For this we are adding a new argument {{--maxRevisionsToCheck}} (with default
value 1).
> Configure the maximum number of revisions to be checked by consistency check
>
>
> Key: OAK-8703
> URL: https://issues.apache.org/jira/browse/OAK-8703
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: oak-run, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8703-02.patch, OAK-8703.patch
>
>
> We need the ability to configure the maximum number of revisions to be
> checked by {{oak-run check}}. This way we can quickly tell whether there's a
> valid revision in the last {{n}} revisions. Moreover, this comes handy when
> we want to test only the last revision (current head state) of the repository.
> For this we can add a new optional argument {{--maxRevisionsToCheck}}. If the
> argument is used, but a specific number of revisions is not specified, the
> tool will check by default only the last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[
https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16956062#comment-16956062
]
Andrei Dulceanu commented on OAK-8703:
--
[~ierandra], how about renaming the argument to {{--last}} with the meaning to
check only the last revision when there's not any number of revisions
specified, otherwise check last {{n}}?
> Configure the maximum number of revisions to be checked by consistency check
>
>
> Key: OAK-8703
> URL: https://issues.apache.org/jira/browse/OAK-8703
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: oak-run, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8703-02.patch, OAK-8703.patch
>
>
> We need the ability to configure the maximum number of revisions to be
> checked by {{oak-run check}}. This way we can quickly tell whether there's a
> valid revision in the last {{n}} revisions. Moreover, this comes handy when
> we want to test only the last revision (current head state) of the repository.
> For this we can add a new optional argument {{--maxRevisionsToCheck}}. If the
> argument is used, but a specific number of revisions is not specified, the
> tool will check by default only the last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[
https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16956126#comment-16956126
]
Andrei Dulceanu commented on OAK-8703:
--
[~ierandra], applying the patch fails for me because of this line in the patch:
{noformat}
can't find file to patch at input line 8
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Index:
jackrabbit-oak/oak-run/src/main/java/org/apache/jackrabbit/oak/run/CheckCommand.java
|IDEA additional info:
|Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
|<+>UTF-8
{noformat}
Can you please use this command when creating the patch: {{git diff --no-prefix
upstream-trunk > your-patch.patch}}?
> Configure the maximum number of revisions to be checked by consistency check
>
>
> Key: OAK-8703
> URL: https://issues.apache.org/jira/browse/OAK-8703
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: oak-run, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8703-02.patch, OAK-8703.patch
>
>
> We need the ability to configure the maximum number of revisions to be
> checked by {{oak-run check}}. This way we can quickly tell whether there's a
> valid revision in the last {{n}} revisions. Moreover, this comes handy when
> we want to test only the last revision (current head state) of the repository.
> For this we can add a new optional argument {{--maxRevisionsToCheck}}. If the
> argument is used, but a specific number of revisions is not specified, the
> tool will check by default only the last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[
https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957191#comment-16957191
]
Andrei Dulceanu commented on OAK-8703:
--
[~ierandra], I made some docs changes and also minor improvements to your
version. Thanks for the contribution!
Fixed in trunk at r1868765.
> Configure the maximum number of revisions to be checked by consistency check
>
>
> Key: OAK-8703
> URL: https://issues.apache.org/jira/browse/OAK-8703
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: oak-run, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8703-02.patch, OAK-8703-03.patch, OAK-8703-04.patch,
> OAK-8703.patch
>
>
> We need the ability to configure the maximum number of revisions to be
> checked by {{oak-run check}}. This way we can quickly tell whether there's a
> valid revision in the last {{n}} revisions. Moreover, this comes handy when
> we want to test only the last revision (current head state) of the repository.
> For this we can add a new optional argument {{--maxRevisionsToCheck}}. If the
> argument is used, but a specific number of revisions is not specified, the
> tool will check by default only the last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8703) Configure the maximum number of revisions to be checked by consistency check
[
https://issues.apache.org/jira/browse/OAK-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8703.
--
Fix Version/s: 1.20.0
Resolution: Fixed
> Configure the maximum number of revisions to be checked by consistency check
>
>
> Key: OAK-8703
> URL: https://issues.apache.org/jira/browse/OAK-8703
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: oak-run, segment-tar
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8703-02.patch, OAK-8703-03.patch, OAK-8703-04.patch,
> OAK-8703.patch
>
>
> We need the ability to configure the maximum number of revisions to be
> checked by {{oak-run check}}. This way we can quickly tell whether there's a
> valid revision in the last {{n}} revisions. Moreover, this comes handy when
> we want to test only the last revision (current head state) of the repository.
> For this we can add a new optional argument {{--maxRevisionsToCheck}}. If the
> argument is used, but a specific number of revisions is not specified, the
> tool will check by default only the last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-8413) Use the new Azure SDK in the Azure Segment Store
[
https://issues.apache.org/jira/browse/OAK-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-8413:
Assignee: Andrei Dulceanu (was: Matt Ryan)
> Use the new Azure SDK in the Azure Segment Store
>
>
> Key: OAK-8413
> URL: https://issues.apache.org/jira/browse/OAK-8413
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure
>Reporter: Tomek Rękawek
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
>
> We should update the oak-segment-azure to use the most recent Azure SDK
> version, to keep it compatible with the oak-blob-cloud-azure (see OAK-8105):
> {code}
>
> com.microsoft.azure
> azure-storage-blob
> 11.0.1
>
> {code}
> //cc: [~mattvryan]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8413) Use the new Azure SDK in the Azure Segment Store
[
https://issues.apache.org/jira/browse/OAK-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16959572#comment-16959572
]
Andrei Dulceanu commented on OAK-8413:
--
[~mattvryan], assigning the issue to me, as discussed. Thanks for sharing the
github branch you were working on!
> Use the new Azure SDK in the Azure Segment Store
>
>
> Key: OAK-8413
> URL: https://issues.apache.org/jira/browse/OAK-8413
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure
>Reporter: Tomek Rękawek
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
>
> We should update the oak-segment-azure to use the most recent Azure SDK
> version, to keep it compatible with the oak-blob-cloud-azure (see OAK-8105):
> {code}
>
> com.microsoft.azure
> azure-storage-blob
> 11.0.1
>
> {code}
> //cc: [~mattvryan]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8719) Oak run job must return the status of repository consistency check
[ https://issues.apache.org/jira/browse/OAK-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8719: - Summary: Oak run job must return the status of repository consistency check (was: Oak run job must return the status of repository consistency) > Oak run job must return the status of repository consistency check > -- > > Key: OAK-8719 > URL: https://issues.apache.org/jira/browse/OAK-8719 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Ieran Draghiciu >Priority: Major > Labels: oak-run, segment-tar > Attachments: OAK-8719.patch > > > Currently the consistency check reports only if the job runs successfully > (return code 0) or fails (return code 1). > Into this logic will also add the status of repository consistency: > - checking only the last revision: will return 0 if the revision is > consistent and the job runs successfully OR will return 1 if the revision is > inconsistent or job did not run successfully (some errors/exception were > encounter during the run) > - checking multiple revisions: will return 0 if at least one revision is > consistent and the job runs successfully OR will return 1 if none of the > revisions are consistent or job did not run successfully (some > errors/exception were encounter during the run) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8719) Oak run check command must return the status of repository consistency check
[ https://issues.apache.org/jira/browse/OAK-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-8719: Assignee: Andrei Dulceanu > Oak run check command must return the status of repository consistency check > > > Key: OAK-8719 > URL: https://issues.apache.org/jira/browse/OAK-8719 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Labels: oak-run, segment-tar > Attachments: OAK-8719.patch > > > Currently the consistency check reports only if the job runs successfully > (return code 0) or fails (return code 1). > Into this logic will also add the status of repository consistency: > - checking only the last revision: will return 0 if the revision is > consistent and the job runs successfully OR will return 1 if the revision is > inconsistent or job did not run successfully (some errors/exception were > encounter during the run) > - checking multiple revisions: will return 0 if at least one revision is > consistent and the job runs successfully OR will return 1 if none of the > revisions are consistent or job did not run successfully (some > errors/exception were encounter during the run) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8719) Oak run check command must return the status of repository consistency check
[ https://issues.apache.org/jira/browse/OAK-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8719: - Summary: Oak run check command must return the status of repository consistency check (was: Oak run job must return the status of repository consistency check) > Oak run check command must return the status of repository consistency check > > > Key: OAK-8719 > URL: https://issues.apache.org/jira/browse/OAK-8719 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Ieran Draghiciu >Priority: Major > Labels: oak-run, segment-tar > Attachments: OAK-8719.patch > > > Currently the consistency check reports only if the job runs successfully > (return code 0) or fails (return code 1). > Into this logic will also add the status of repository consistency: > - checking only the last revision: will return 0 if the revision is > consistent and the job runs successfully OR will return 1 if the revision is > inconsistent or job did not run successfully (some errors/exception were > encounter during the run) > - checking multiple revisions: will return 0 if at least one revision is > consistent and the job runs successfully OR will return 1 if none of the > revisions are consistent or job did not run successfully (some > errors/exception were encounter during the run) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8719) Oak run check command must return the status of repository consistency check
[ https://issues.apache.org/jira/browse/OAK-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8719: - Description: Currently the consistency check reports only if the command runs successfully (return code 0) or fails (return code 1). Into this logic will also add the status of repository consistency: - checking only the last revision: will return 0 if the revision is consistent and the command runs successfully OR will return 1 if the revision is inconsistent or job did not run successfully (some errors/exception were encountered during the run) - checking multiple revisions: will return 0 if at least one revision is consistent and the job runs successfully OR will return 1 if none of the revisions are consistent or the command did not run successfully (some errors/exception were encounter during the run) was: Currently the consistency check reports only if the job runs successfully (return code 0) or fails (return code 1). Into this logic will also add the status of repository consistency: - checking only the last revision: will return 0 if the revision is consistent and the job runs successfully OR will return 1 if the revision is inconsistent or job did not run successfully (some errors/exception were encounter during the run) - checking multiple revisions: will return 0 if at least one revision is consistent and the job runs successfully OR will return 1 if none of the revisions are consistent or job did not run successfully (some errors/exception were encounter during the run) > Oak run check command must return the status of repository consistency check > > > Key: OAK-8719 > URL: https://issues.apache.org/jira/browse/OAK-8719 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Labels: oak-run, segment-tar > Attachments: OAK-8719.patch > > > Currently the consistency check reports only if the command runs successfully > (return code 0) or fails (return code 1). > Into this logic will also add the status of repository consistency: > - checking only the last revision: will return 0 if the revision is > consistent and the command runs successfully OR will return 1 if the revision > is inconsistent or job did not run successfully (some errors/exception were > encountered during the run) > - checking multiple revisions: will return 0 if at least one revision is > consistent and the job runs successfully OR will return 1 if none of the > revisions are consistent or the command did not run successfully (some > errors/exception were encounter during the run) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8413) Use the new Azure SDK in the Azure Segment Store
[
https://issues.apache.org/jira/browse/OAK-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16960989#comment-16960989
]
Andrei Dulceanu commented on OAK-8413:
--
[~wingeier], I can't assign you to the issue (I guess it's only for
committers). Please ping me here if you are blocked or have questions. Thanks!
> Use the new Azure SDK in the Azure Segment Store
>
>
> Key: OAK-8413
> URL: https://issues.apache.org/jira/browse/OAK-8413
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure
>Reporter: Tomek Rękawek
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
>
> We should update the oak-segment-azure to use the most recent Azure SDK
> version, to keep it compatible with the oak-blob-cloud-azure (see OAK-8105):
> {code}
>
> com.microsoft.azure
> azure-storage-blob
> 11.0.1
>
> {code}
> //cc: [~mattvryan]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8719) Oak run check command must return the status of repository consistency check
[
https://issues.apache.org/jira/browse/OAK-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961091#comment-16961091
]
Andrei Dulceanu commented on OAK-8719:
--
[~ierandra], I'd prefer to not add the new {{isRepositoryConsistent}} instance
variable, because it's kind of useless. Rather, I'd like to make the actual
{{run}} method [0] inside {{Check}} return a suitable exit code which would be
used by the calling method for reporting success/failure.
[0]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/tool/Check.java#L400
> Oak run check command must return the status of repository consistency check
>
>
> Key: OAK-8719
> URL: https://issues.apache.org/jira/browse/OAK-8719
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Ieran Draghiciu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: oak-run, segment-tar
> Attachments: OAK-8719.patch
>
>
> Currently the consistency check reports only if the command runs successfully
> (return code 0) or fails (return code 1).
> Into this logic will also add the status of repository consistency:
> - checking only the last revision: will return 0 if the revision is
> consistent and the command runs successfully OR will return 1 if the revision
> is inconsistent or job did not run successfully (some errors/exception were
> encountered during the run)
> - checking multiple revisions: will return 0 if at least one revision is
> consistent and the job runs successfully OR will return 1 if none of the
> revisions are consistent or the command did not run successfully (some
> errors/exception were encounter during the run)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8719) Oak run check command must return the status of repository consistency check
[ https://issues.apache.org/jira/browse/OAK-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961225#comment-16961225 ] Andrei Dulceanu commented on OAK-8719: -- Fixed in trunk (with a minor variable name change) at r1869082. Thanks for the contribution, [~ierandra]! > Oak run check command must return the status of repository consistency check > > > Key: OAK-8719 > URL: https://issues.apache.org/jira/browse/OAK-8719 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Labels: oak-run, segment-tar > Attachments: OAK-8719-1.patch, OAK-8719.patch > > > Currently the consistency check reports only if the command runs successfully > (return code 0) or fails (return code 1). > Into this logic will also add the status of repository consistency: > - checking only the last revision: will return 0 if the revision is > consistent and the command runs successfully OR will return 1 if the revision > is inconsistent or job did not run successfully (some errors/exception were > encountered during the run) > - checking multiple revisions: will return 0 if at least one revision is > consistent and the job runs successfully OR will return 1 if none of the > revisions are consistent or the command did not run successfully (some > errors/exception were encounter during the run) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8719) Oak run check command must return the status of repository consistency check
[ https://issues.apache.org/jira/browse/OAK-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-8719. -- Fix Version/s: 1.20.0 Resolution: Fixed > Oak run check command must return the status of repository consistency check > > > Key: OAK-8719 > URL: https://issues.apache.org/jira/browse/OAK-8719 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Ieran Draghiciu >Assignee: Andrei Dulceanu >Priority: Major > Labels: oak-run, segment-tar > Fix For: 1.20.0 > > Attachments: OAK-8719-1.patch, OAK-8719.patch > > > Currently the consistency check reports only if the command runs successfully > (return code 0) or fails (return code 1). > Into this logic will also add the status of repository consistency: > - checking only the last revision: will return 0 if the revision is > consistent and the command runs successfully OR will return 1 if the revision > is inconsistent or job did not run successfully (some errors/exception were > encountered during the run) > - checking multiple revisions: will return 0 if at least one revision is > consistent and the job runs successfully OR will return 1 if none of the > revisions are consistent or the command did not run successfully (some > errors/exception were encounter during the run) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8750) SegmentStoreMigrator should catch and log exceptions thrown while migrating archives
Andrei Dulceanu created OAK-8750:
Summary: SegmentStoreMigrator should catch and log exceptions
thrown while migrating archives
Key: OAK-8750
URL: https://issues.apache.org/jira/browse/OAK-8750
Project: Jackrabbit Oak
Issue Type: Task
Components: segment-azure
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Fix For: 1.20.0
Current logic used in migrating archives in {{SegmentStoreMigrator}} silently
swallows exceptions coming from the segment, binary refs and graph migration
methods:
{noformat}
try (SegmentArchiveReader reader = sourceManager.forceOpen(archiveName)) {
SegmentArchiveWriter writer = targetManager.create(archiveName);
try {
migrateSegments(reader, writer);
migrateBinaryRef(reader, writer);
migrateGraph(reader, writer);
} finally {
writer.close();
}
}
{noformat}
Adding a catch block which logs the possible exceptions would make analysing
logs easier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8750) SegmentStoreMigrator should catch and log exceptions thrown while migrating archives
[
https://issues.apache.org/jira/browse/OAK-8750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8750:
-
Attachment: OAK-8750.patch
> SegmentStoreMigrator should catch and log exceptions thrown while migrating
> archives
>
>
> Key: OAK-8750
> URL: https://issues.apache.org/jira/browse/OAK-8750
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8750.patch
>
>
> Current logic used in migrating archives in {{SegmentStoreMigrator}} silently
> swallows exceptions coming from the segment, binary refs and graph migration
> methods:
> {noformat}
> try (SegmentArchiveReader reader = sourceManager.forceOpen(archiveName)) {
> SegmentArchiveWriter writer = targetManager.create(archiveName);
> try {
> migrateSegments(reader, writer);
> migrateBinaryRef(reader, writer);
> migrateGraph(reader, writer);
> } finally {
> writer.close();
> }
> }
> {noformat}
> Adding a catch block which logs the possible exceptions would make analysing
> logs easier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8750) SegmentStoreMigrator should catch and log exceptions thrown while migrating archives
[
https://issues.apache.org/jira/browse/OAK-8750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8750.
--
Resolution: Fixed
Fixed in trunk at r1869544.
> SegmentStoreMigrator should catch and log exceptions thrown while migrating
> archives
>
>
> Key: OAK-8750
> URL: https://issues.apache.org/jira/browse/OAK-8750
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8750.patch
>
>
> Current logic used in migrating archives in {{SegmentStoreMigrator}} silently
> swallows exceptions coming from the segment, binary refs and graph migration
> methods:
> {noformat}
> try (SegmentArchiveReader reader = sourceManager.forceOpen(archiveName)) {
> SegmentArchiveWriter writer = targetManager.create(archiveName);
> try {
> migrateSegments(reader, writer);
> migrateBinaryRef(reader, writer);
> migrateGraph(reader, writer);
> } finally {
> writer.close();
> }
> }
> {noformat}
> Adding a catch block which logs the possible exceptions would make analysing
> logs easier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8751) SegmentCopyCommand does not support verbose option anymore
Andrei Dulceanu created OAK-8751:
Summary: SegmentCopyCommand does not support verbose option anymore
Key: OAK-8751
URL: https://issues.apache.org/jira/browse/OAK-8751
Project: Jackrabbit Oak
Issue Type: Documentation
Components: segment-azure, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Invoking {{oak-run segment-copy}} with the {{--verbose}} options fails with
unrecognised option exception. We should update the documentation for {{oak-run
segment-copy}} to remove references to missing option.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8751) SegmentCopyCommand does not support verbose option anymore
[
https://issues.apache.org/jira/browse/OAK-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu closed OAK-8751.
> SegmentCopyCommand does not support verbose option anymore
> --
>
> Key: OAK-8751
> URL: https://issues.apache.org/jira/browse/OAK-8751
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.20.0
>
>
> Invoking {{oak-run segment-copy}} with the {{--verbose}} options fails with
> unrecognised option exception. We should update the documentation for
> {{oak-run segment-copy}} to remove references to missing option.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8751) SegmentCopyCommand does not support verbose option anymore
[
https://issues.apache.org/jira/browse/OAK-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8751.
--
Fix Version/s: 1.20.0
Resolution: Fixed
Fixed in trunk at r1869545.
> SegmentCopyCommand does not support verbose option anymore
> --
>
> Key: OAK-8751
> URL: https://issues.apache.org/jira/browse/OAK-8751
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.20.0
>
>
> Invoking {{oak-run segment-copy}} with the {{--verbose}} options fails with
> unrecognised option exception. We should update the documentation for
> {{oak-run segment-copy}} to remove references to missing option.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8750) SegmentStoreMigrator should catch and log exceptions thrown while migrating archives
[
https://issues.apache.org/jira/browse/OAK-8750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu closed OAK-8750.
> SegmentStoreMigrator should catch and log exceptions thrown while migrating
> archives
>
>
> Key: OAK-8750
> URL: https://issues.apache.org/jira/browse/OAK-8750
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: OAK-8750.patch
>
>
> Current logic used in migrating archives in {{SegmentStoreMigrator}} silently
> swallows exceptions coming from the segment, binary refs and graph migration
> methods:
> {noformat}
> try (SegmentArchiveReader reader = sourceManager.forceOpen(archiveName)) {
> SegmentArchiveWriter writer = targetManager.create(archiveName);
> try {
> migrateSegments(reader, writer);
> migrateBinaryRef(reader, writer);
> migrateGraph(reader, writer);
> } finally {
> writer.close();
> }
> }
> {noformat}
> Adding a catch block which logs the possible exceptions would make analysing
> logs easier.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8752) SegmentCopy should not lock/unlock source repository while before/after copying
Andrei Dulceanu created OAK-8752:
Summary: SegmentCopy should not lock/unlock source repository
while before/after copying
Key: OAK-8752
URL: https://issues.apache.org/jira/browse/OAK-8752
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-azure, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Since SegmentStoreMigrator already supports migrating a repository which is
still written to at the time of migration, I think we should remove the
unnecessary locking/unlocking before/after doing the actual copying.
One can use {{oak-run check}} for checking the consistency of the resulted
migrated repository after the migration is done, just to double-check that
everything is ok.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8752) SegmentCopy should not lock/unlock source repository while before/after copying
[
https://issues.apache.org/jira/browse/OAK-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970117#comment-16970117
]
Andrei Dulceanu commented on OAK-8752:
--
[~tomekr], do you have any concerns re. this?
> SegmentCopy should not lock/unlock source repository while before/after
> copying
> ---
>
> Key: OAK-8752
> URL: https://issues.apache.org/jira/browse/OAK-8752
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> Since SegmentStoreMigrator already supports migrating a repository which is
> still written to at the time of migration, I think we should remove the
> unnecessary locking/unlocking before/after doing the actual copying.
> One can use {{oak-run check}} for checking the consistency of the resulted
> migrated repository after the migration is done, just to double-check that
> everything is ok.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8752) SegmentCopy should not lock/unlock source repository before/after copying
[
https://issues.apache.org/jira/browse/OAK-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8752:
-
Summary: SegmentCopy should not lock/unlock source repository before/after
copying (was: SegmentCopy should not lock/unlock source repository while
before/after copying)
> SegmentCopy should not lock/unlock source repository before/after copying
> -
>
> Key: OAK-8752
> URL: https://issues.apache.org/jira/browse/OAK-8752
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> Since SegmentStoreMigrator already supports migrating a repository which is
> still written to at the time of migration, I think we should remove the
> unnecessary locking/unlocking before/after doing the actual copying.
> One can use {{oak-run check}} for checking the consistency of the resulted
> migrated repository after the migration is done, just to double-check that
> everything is ok.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8752) SegmentCopy should not lock/unlock source repository before/after copying
[
https://issues.apache.org/jira/browse/OAK-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu closed OAK-8752.
> SegmentCopy should not lock/unlock source repository before/after copying
> -
>
> Key: OAK-8752
> URL: https://issues.apache.org/jira/browse/OAK-8752
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.20.0
>
>
> Since SegmentStoreMigrator already supports migrating a repository which is
> still written to at the time of migration, I think we should remove the
> unnecessary locking/unlocking before/after doing the actual copying.
> One can use {{oak-run check}} for checking the consistency of the resulted
> migrated repository after the migration is done, just to double-check that
> everything is ok.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8752) SegmentCopy should not lock/unlock source repository before/after copying
[
https://issues.apache.org/jira/browse/OAK-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8752.
--
Fix Version/s: 1.20.0
Resolution: Fixed
Thanks for chiming in, [~tomekr]!
Fixed in trunk at r1869569.
> SegmentCopy should not lock/unlock source repository before/after copying
> -
>
> Key: OAK-8752
> URL: https://issues.apache.org/jira/browse/OAK-8752
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.20.0
>
>
> Since SegmentStoreMigrator already supports migrating a repository which is
> still written to at the time of migration, I think we should remove the
> unnecessary locking/unlocking before/after doing the actual copying.
> One can use {{oak-run check}} for checking the consistency of the resulted
> migrated repository after the migration is done, just to double-check that
> everything is ok.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8754) Segment-copy command is broken due to unsatisfied dependency to commons-lang 3.x
Andrei Dulceanu created OAK-8754:
Summary: Segment-copy command is broken due to unsatisfied
dependency to commons-lang 3.x
Key: OAK-8754
URL: https://issues.apache.org/jira/browse/OAK-8754
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-azure
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Running the segment-copy command to transfer a repo from Azure to local
storage, I get this:
{noformat}
$ java -jar oak-run-1.20-SNAPSHOT.jar segment-copy az:/directory .
Apache Jackrabbit Oak 1.20-SNAPSHOT
Started segment-copy transfer!
Source: Azure Segment Store@/directory
Destination: TarMK Segment Store@.
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/commons/lang3/StringUtils
at
org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrateJournal(SegmentStoreMigrator.java:107)
at
org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.lambda$migrate$0(SegmentStoreMigrator.java:90)
at
org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.runWithRetry(SegmentStoreMigrator.java:218)
at
org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrate(SegmentStoreMigrator.java:90)
at
org.apache.jackrabbit.oak.segment.azure.tool.SegmentCopy.run(SegmentCopy.java:203)
at
org.apache.jackrabbit.oak.run.SegmentCopyCommand.execute(SegmentCopyCommand.java:52)
at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.lang3.StringUtils
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8754) Segment-copy command is broken due to unsatisfied dependency to commons-lang 3.x
[
https://issues.apache.org/jira/browse/OAK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970392#comment-16970392
]
Andrei Dulceanu commented on OAK-8754:
--
[~tomekr], I think that dependency is available only in test scope. The current
commons-lang from oak-parent/pom.xml is 2.6:
{noformat}
commons-lang
commons-lang
2.6
{noformat}
Could you please run the above and confirm if it's happening for you as well?
Three ways moving forward here: update the dependency version in oak-parent,
add the correct dependency to oak-segment-azure or just remove the offending
code, as this can be handled ad-hoc in our own method. I'd prefer the third
option. Let me know your thoughts and I'll make the adjustments.
> Segment-copy command is broken due to unsatisfied dependency to commons-lang
> 3.x
>
>
> Key: OAK-8754
> URL: https://issues.apache.org/jira/browse/OAK-8754
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> Running the segment-copy command to transfer a repo from Azure to local
> storage, I get this:
> {noformat}
> $ java -jar oak-run-1.20-SNAPSHOT.jar segment-copy az:/directory .
> Apache Jackrabbit Oak 1.20-SNAPSHOT
> Started segment-copy transfer!
> Source: Azure Segment Store@/directory
> Destination: TarMK Segment Store@.
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/commons/lang3/StringUtils
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrateJournal(SegmentStoreMigrator.java:107)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.lambda$migrate$0(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.runWithRetry(SegmentStoreMigrator.java:218)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrate(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentCopy.run(SegmentCopy.java:203)
> at
> org.apache.jackrabbit.oak.run.SegmentCopyCommand.execute(SegmentCopyCommand.java:52)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8755) Validate segments migration with a SegmentStoreMigratorTest
Andrei Dulceanu created OAK-8755: Summary: Validate segments migration with a SegmentStoreMigratorTest Key: OAK-8755 URL: https://issues.apache.org/jira/browse/OAK-8755 Project: Jackrabbit Oak Issue Type: Task Components: segment-azure, segment-tar Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu We currently don't have unit tests/IT for validating our segment migration from local tar to Azure and the other way round. We need to have something in place to quickly validate changes in this area. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8754) Segment-copy command is broken due to unsatisfied dependency to commons-lang 3.x
[
https://issues.apache.org/jira/browse/OAK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8754:
-
Attachment: OAK-8754.patch
> Segment-copy command is broken due to unsatisfied dependency to commons-lang
> 3.x
>
>
> Key: OAK-8754
> URL: https://issues.apache.org/jira/browse/OAK-8754
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8754.patch
>
>
> Running the segment-copy command to transfer a repo from Azure to local
> storage, I get this:
> {noformat}
> $ java -jar oak-run-1.20-SNAPSHOT.jar segment-copy az:/directory .
> Apache Jackrabbit Oak 1.20-SNAPSHOT
> Started segment-copy transfer!
> Source: Azure Segment Store@/directory
> Destination: TarMK Segment Store@.
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/commons/lang3/StringUtils
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrateJournal(SegmentStoreMigrator.java:107)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.lambda$migrate$0(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.runWithRetry(SegmentStoreMigrator.java:218)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrate(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentCopy.run(SegmentCopy.java:203)
> at
> org.apache.jackrabbit.oak.run.SegmentCopyCommand.execute(SegmentCopyCommand.java:52)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8754) Segment-copy command is broken due to unsatisfied dependency to commons-lang 3.x
[
https://issues.apache.org/jira/browse/OAK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8754.
--
Resolution: Fixed
[~tomekr], I went ahead and fixed this with the third option. Please find the
patch attached.
Fixed at r1869658.
> Segment-copy command is broken due to unsatisfied dependency to commons-lang
> 3.x
>
>
> Key: OAK-8754
> URL: https://issues.apache.org/jira/browse/OAK-8754
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8754.patch
>
>
> Running the segment-copy command to transfer a repo from Azure to local
> storage, I get this:
> {noformat}
> $ java -jar oak-run-1.20-SNAPSHOT.jar segment-copy az:/directory .
> Apache Jackrabbit Oak 1.20-SNAPSHOT
> Started segment-copy transfer!
> Source: Azure Segment Store@/directory
> Destination: TarMK Segment Store@.
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/commons/lang3/StringUtils
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrateJournal(SegmentStoreMigrator.java:107)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.lambda$migrate$0(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.runWithRetry(SegmentStoreMigrator.java:218)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrate(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentCopy.run(SegmentCopy.java:203)
> at
> org.apache.jackrabbit.oak.run.SegmentCopyCommand.execute(SegmentCopyCommand.java:52)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8754) Segment-copy command is broken due to unsatisfied dependency to commons-lang 3.x
[
https://issues.apache.org/jira/browse/OAK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu closed OAK-8754.
> Segment-copy command is broken due to unsatisfied dependency to commons-lang
> 3.x
>
>
> Key: OAK-8754
> URL: https://issues.apache.org/jira/browse/OAK-8754
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: OAK-8754.patch
>
>
> Running the segment-copy command to transfer a repo from Azure to local
> storage, I get this:
> {noformat}
> $ java -jar oak-run-1.20-SNAPSHOT.jar segment-copy az:/directory .
> Apache Jackrabbit Oak 1.20-SNAPSHOT
> Started segment-copy transfer!
> Source: Azure Segment Store@/directory
> Destination: TarMK Segment Store@.
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/commons/lang3/StringUtils
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrateJournal(SegmentStoreMigrator.java:107)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.lambda$migrate$0(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.runWithRetry(SegmentStoreMigrator.java:218)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentStoreMigrator.migrate(SegmentStoreMigrator.java:90)
> at
> org.apache.jackrabbit.oak.segment.azure.tool.SegmentCopy.run(SegmentCopy.java:203)
> at
> org.apache.jackrabbit.oak.run.SegmentCopyCommand.execute(SegmentCopyCommand.java:52)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:49)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8755) Validate segments migration with a SegmentStoreMigratorIT
[ https://issues.apache.org/jira/browse/OAK-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8755: - Summary: Validate segments migration with a SegmentStoreMigratorIT (was: Validate segments migration with a SegmentStoreMigratorTest) > Validate segments migration with a SegmentStoreMigratorIT > - > > Key: OAK-8755 > URL: https://issues.apache.org/jira/browse/OAK-8755 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-azure, segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > We currently don't have unit tests/IT for validating our segment migration > from local tar to Azure and the other way round. We need to have something in > place to quickly validate changes in this area. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8756) Oak-run segment-copy command logging documentation
Andrei Dulceanu created OAK-8756:
Summary: Oak-run segment-copy command logging documentation
Key: OAK-8756
URL: https://issues.apache.org/jira/browse/OAK-8756
Project: Jackrabbit Oak
Issue Type: Documentation
Components: oak-run, segment-azure
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Since we deprecated the old {{--verbose}} option, operations are not logged
anymore when issuing {{oak-run segment-copy src dest}}. It would be nice to add
some docs on how to set up the logging so that individual transfers (journal,
manifest, gc.log and each archive) are logged again to the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8756) Oak-run segment-copy command logging documentation
[
https://issues.apache.org/jira/browse/OAK-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8756.
--
Resolution: Fixed
Fixed at r1869699.
> Oak-run segment-copy command logging documentation
> --
>
> Key: OAK-8756
> URL: https://issues.apache.org/jira/browse/OAK-8756
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: oak-run, segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> Since we deprecated the old {{--verbose}} option, operations are not logged
> anymore when issuing {{oak-run segment-copy src dest}}. It would be nice to
> add some docs on how to set up the logging so that individual transfers
> (journal, manifest, gc.log and each archive) are logged again to the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8756) Oak-run segment-copy command logging documentation
[
https://issues.apache.org/jira/browse/OAK-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8756:
-
Fix Version/s: 1.20.0
> Oak-run segment-copy command logging documentation
> --
>
> Key: OAK-8756
> URL: https://issues.apache.org/jira/browse/OAK-8756
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: oak-run, segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
>
> Since we deprecated the old {{--verbose}} option, operations are not logged
> anymore when issuing {{oak-run segment-copy src dest}}. It would be nice to
> add some docs on how to set up the logging so that individual transfers
> (journal, manifest, gc.log and each archive) are logged again to the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8756) Oak-run segment-copy command logging documentation
[
https://issues.apache.org/jira/browse/OAK-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu closed OAK-8756.
> Oak-run segment-copy command logging documentation
> --
>
> Key: OAK-8756
> URL: https://issues.apache.org/jira/browse/OAK-8756
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: oak-run, segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.20.0
>
>
> Since we deprecated the old {{--verbose}} option, operations are not logged
> anymore when issuing {{oak-run segment-copy src dest}}. It would be nice to
> add some docs on how to set up the logging so that individual transfers
> (journal, manifest, gc.log and each archive) are logged again to the console.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8765) oak-run segment-copy command should include option to specify the number of entries to transfer from the journal
Andrei Dulceanu created OAK-8765:
Summary: oak-run segment-copy command should include option to
specify the number of entries to transfer from the journal
Key: OAK-8765
URL: https://issues.apache.org/jira/browse/OAK-8765
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-azure, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
In {{SegmentStoreMigrator}} we already have the option to transfer only the
last revision of the journal, but this is not yet exposed in
{{SegmentCopyCommand}}. It would be nice to make it more flexible and include
also a {{--last}} option as we already have for {{oak-run check}} to specify
the number of entries to transfer.
/cc [~tomekr]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8826) Update incorrect logback segment-copy configuration file name
Andrei Dulceanu created OAK-8826:
Summary: Update incorrect logback segment-copy configuration file
name
Key: OAK-8826
URL: https://issues.apache.org/jira/browse/OAK-8826
Project: Jackrabbit Oak
Issue Type: Documentation
Components: segment-azure, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
The section at [0] incorrectly mentions {{logback-compaction.xml}} when talking
about {{logback-segment-copy.xml}}.
https://jackrabbit.apache.org/oak/docs/nodestore/segment/overview.html#segment-copy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8826) Update incorrect logback segment-copy configuration file name
[
https://issues.apache.org/jira/browse/OAK-8826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8826.
--
Fix Version/s: 1.22.0
Resolution: Fixed
Fixed in trunk at r1871129.
> Update incorrect logback segment-copy configuration file name
> -
>
> Key: OAK-8826
> URL: https://issues.apache.org/jira/browse/OAK-8826
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Trivial
> Fix For: 1.22.0
>
>
> The section at [0] incorrectly mentions {{logback-compaction.xml}} when
> talking about {{logback-segment-copy.xml}}.
> https://jackrabbit.apache.org/oak/docs/nodestore/segment/overview.html#segment-copy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8827) AWS support for segment-tar
Andrei Dulceanu created OAK-8827: Summary: AWS support for segment-tar Key: OAK-8827 URL: https://issues.apache.org/jira/browse/OAK-8827 Project: Jackrabbit Oak Issue Type: New Feature Components: segment-tar Reporter: Andrei Dulceanu -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8828) Configure the maximum number of journal entries to be copied with segment-copy
Andrei Dulceanu created OAK-8828:
Summary: Configure the maximum number of journal entries to be
copied with segment-copy
Key: OAK-8828
URL: https://issues.apache.org/jira/browse/OAK-8828
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-azure, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
We need the ability to configure the maximum number of revisions to be checked
by {{oak-run segment-copy}}. This way we can void timeout issues when
transferring a large journal over the network with the sole purpose to compact
the repository.
For this we can add a new optional argument {{--last }}, with the
same semantics as {{oak-run check}}. If the argument is used, but a specific
number of revisions is not specified, the tool will check by default only the
last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8828) Configure the maximum number of journal entries to be copied with segment-copy
[
https://issues.apache.org/jira/browse/OAK-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8828:
-
Description:
We need the ability to configure the maximum number of journal entries (i.e.
revisions) to be copied by {{oak-run segment-copy}}. This way we can void
timeout issues when transferring a large journal over the network with the sole
purpose to compact the repository.
For this we can add a new optional argument {{--last }}, with the
same semantics as {{oak-run check}}. If the argument is used, but a specific
number of revisions is not specified, the tool will check by default only the
last revision.
was:
We need the ability to configure the maximum number of revisions to be checked
by {{oak-run segment-copy}}. This way we can void timeout issues when
transferring a large journal over the network with the sole purpose to compact
the repository.
For this we can add a new optional argument {{--last }}, with the
same semantics as {{oak-run check}}. If the argument is used, but a specific
number of revisions is not specified, the tool will check by default only the
last revision.
> Configure the maximum number of journal entries to be copied with segment-copy
> --
>
> Key: OAK-8828
> URL: https://issues.apache.org/jira/browse/OAK-8828
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> We need the ability to configure the maximum number of journal entries (i.e.
> revisions) to be copied by {{oak-run segment-copy}}. This way we can void
> timeout issues when transferring a large journal over the network with the
> sole purpose to compact the repository.
> For this we can add a new optional argument {{--last }}, with the
> same semantics as {{oak-run check}}. If the argument is used, but a specific
> number of revisions is not specified, the tool will check by default only the
> last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8828) Configure the maximum number of journal entries to be copied with segment-copy
[
https://issues.apache.org/jira/browse/OAK-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8828:
-
Description:
We need the ability to configure the maximum number of journal entries (i.e.
revisions) to be copied by {{oak-run segment-copy}}. This way we can void
timeout issues when transferring a large journal over the network with the sole
purpose to compact the repository.
For this we can add a new optional argument {{--last }}, with the
same semantics as {{oak-run check}}. If the argument is used, but a specific
number of revisions is not specified, the tool will copy by default only the
last revision.
was:
We need the ability to configure the maximum number of journal entries (i.e.
revisions) to be copied by {{oak-run segment-copy}}. This way we can void
timeout issues when transferring a large journal over the network with the sole
purpose to compact the repository.
For this we can add a new optional argument {{--last }}, with the
same semantics as {{oak-run check}}. If the argument is used, but a specific
number of revisions is not specified, the tool will check by default only the
last revision.
> Configure the maximum number of journal entries to be copied with segment-copy
> --
>
> Key: OAK-8828
> URL: https://issues.apache.org/jira/browse/OAK-8828
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> We need the ability to configure the maximum number of journal entries (i.e.
> revisions) to be copied by {{oak-run segment-copy}}. This way we can void
> timeout issues when transferring a large journal over the network with the
> sole purpose to compact the repository.
> For this we can add a new optional argument {{--last }}, with the
> same semantics as {{oak-run check}}. If the argument is used, but a specific
> number of revisions is not specified, the tool will copy by default only the
> last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8828) Configure the maximum number of journal entries to be copied with segment-copy
[
https://issues.apache.org/jira/browse/OAK-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992711#comment-16992711
]
Andrei Dulceanu commented on OAK-8828:
--
[~ierandra], would you like to work on this one?
/cc [~tomek.rekawek]
> Configure the maximum number of journal entries to be copied with segment-copy
> --
>
> Key: OAK-8828
> URL: https://issues.apache.org/jira/browse/OAK-8828
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> We need the ability to configure the maximum number of revisions to be
> checked by {{oak-run segment-copy}}. This way we can void timeout issues when
> transferring a large journal over the network with the sole purpose to
> compact the repository.
> For this we can add a new optional argument {{--last }}, with the
> same semantics as {{oak-run check}}. If the argument is used, but a specific
> number of revisions is not specified, the tool will check by default only the
> last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8827) AWS support for segment-tar
[ https://issues.apache.org/jira/browse/OAK-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16993204#comment-16993204 ] Andrei Dulceanu commented on OAK-8827: -- [~alvarorahul], it seems you need to be a committer to be able to have issues assigned to you. > AWS support for segment-tar > --- > > Key: OAK-8827 > URL: https://issues.apache.org/jira/browse/OAK-8827 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Andrei Dulceanu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
Andrei Dulceanu created OAK-8832:
Summary: Offline Compaction fails while erroneously accessing
external blob
Key: OAK-8832
URL: https://issues.apache.org/jira/browse/OAK-8832
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Affects Versions: 1.20.0, 1.18.0, 1.16.0, 1.14.0, 1.8.11, 1.12.0, 1.10.0,
1.22.0
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Relevant stack trace:
{noformat}
INFO [2019-12-06 01:07:39,345]
org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting root.
java.lang.IllegalStateException: Attempt to read external blob with blobId
[95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
without specifying BlobStore
INFO [2019-12-06 01:07:39,753]
org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
/mnt/sandbox/tmp/1575594001228-0
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
at
org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
at com.google.common.base.Objects.equal(Objects.java:52)
at
org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
at
org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
at
org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
at
org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
at
org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
at
org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
at
org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
at
org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
at
org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
at
org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
at
org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
at
org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
at
org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
at
org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:440)
at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:398)
at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
at
org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
at
org.apache.jackrabbit.oak.segment
[jira] [Updated] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8832:
-
Issue Type: Bug (was: Improvement)
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.10.0, 1.12.0, 1.8.11, 1.14.0, 1.16.0, 1.18.0, 1.20.0,
> 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.j
[jira] [Resolved] (OAK-8828) Configure the maximum number of journal entries to be copied with segment-copy
[
https://issues.apache.org/jira/browse/OAK-8828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8828.
--
Fix Version/s: 1.22.0
Resolution: Fixed
Fixed in trunk at r1871693.
[~ierandra], the patch was really good! I committed it with minor changes in
trunk. Thanks for your contribution!
> Configure the maximum number of journal entries to be copied with segment-copy
> --
>
> Key: OAK-8828
> URL: https://issues.apache.org/jira/browse/OAK-8828
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.22.0
>
> Attachments: OAK-8828.patch
>
>
> We need the ability to configure the maximum number of journal entries (i.e.
> revisions) to be copied by {{oak-run segment-copy}}. This way we can void
> timeout issues when transferring a large journal over the network with the
> sole purpose to compact the repository.
> For this we can add a new optional argument {{--last }}, with the
> same semantics as {{oak-run check}}. If the argument is used, but a specific
> number of revisions is not specified, the tool will copy by default only the
> last revision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-8827) AWS support for segment-tar
[ https://issues.apache.org/jira/browse/OAK-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-8827: Assignee: Andrei Dulceanu > AWS support for segment-tar > --- > > Key: OAK-8827 > URL: https://issues.apache.org/jira/browse/OAK-8827 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8836) oak-run compact should offer the possibility to choose between checkpoints compactor and the classical compactor
Andrei Dulceanu created OAK-8836:
Summary: oak-run compact should offer the possibility to choose
between checkpoints compactor and the classical compactor
Key: OAK-8836
URL: https://issues.apache.org/jira/browse/OAK-8836
Project: Jackrabbit Oak
Issue Type: Improvement
Components: oak-run, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Until the final fix for OAK-8832 will be out and even after that, I think we
must offer the possibility to do offline compaction in two modes:
* current optimized solution which compacts checkpoints on top of the other,
chronologically and after that the root state on top of those
* previous un-optimized solution which blindly compacts everything, making use
of the deduplication caches to control checkpoints "explosion"
I propose to add an optional argument to compact, {{--mode}} with three values:
auto, diff and classic. When not set, it will just go with whatever we choose
as auto - for now "classic". If set, it will use the mode provided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8837) Refactor FileStore to support pluggable Compactor
Andrei Dulceanu created OAK-8837: Summary: Refactor FileStore to support pluggable Compactor Key: OAK-8837 URL: https://issues.apache.org/jira/browse/OAK-8837 Project: Jackrabbit Oak Issue Type: Task Components: segment-tar Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu In our current implementation it is hard to switch the compactor "flavour" because the actual compactor implementation is hidden under many indirection layers of strategies. We need a quick workaround to support the use-case from OAK-8836, i.e. allowing tooling to change at runtime the default compactor implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8855) Permission evaluation of nodes broken after :nestedCug removed from parent node
[ https://issues.apache.org/jira/browse/OAK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-8855: Assignee: Andrei Dulceanu > Permission evaluation of nodes broken after :nestedCug removed from parent > node > --- > > Key: OAK-8855 > URL: https://issues.apache.org/jira/browse/OAK-8855 > Project: Jackrabbit Oak > Issue Type: Bug > Components: authorization-cug >Reporter: Kunal Shubham >Assignee: Andrei Dulceanu >Priority: Major > Attachments: 0001-Fix-nestedcug-permission-issue.patch > > > Steps to Reproduce: > # Create a node 'a' which has two children nodes 'b1' and 'b2'. The content > tree looks as shown: /content/a/b1, /content/a/b2. Create two users user1 and > user2. > # Apply CUG policy on /content/a. > ** Authorize user1 and user2 to read /content/a. > ** Authorize user1 to read /content/a/b1. > ** Authorize user2 to read /content/a/b2. > # Remove :nestedCugs property from /content/a/rep:cugPolicy. > # Create a content session, login with user2. Try to read /content/a/b1. > *Observed behavior* : user2 is able to read /content/a/b1. > *Expected behavior* : user2 should not be able to read /content/a/b1 as it is > unauthorized to do so. > Please note that :nestedCugs is removed by a mechanism which completely > overwrites content tree below "/content/a". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8855) Permission evaluation of nodes broken after :nestedCug removed from parent node
[ https://issues.apache.org/jira/browse/OAK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8855: - Affects Version/s: 1.6.19 > Permission evaluation of nodes broken after :nestedCug removed from parent > node > --- > > Key: OAK-8855 > URL: https://issues.apache.org/jira/browse/OAK-8855 > Project: Jackrabbit Oak > Issue Type: Bug > Components: authorization-cug >Affects Versions: 1.6.19 >Reporter: Kunal Shubham >Assignee: Andrei Dulceanu >Priority: Major > Attachments: 0001-Fix-nestedcug-permission-issue.patch > > > Steps to Reproduce: > # Create a node 'a' which has two children nodes 'b1' and 'b2'. The content > tree looks as shown: /content/a/b1, /content/a/b2. Create two users user1 and > user2. > # Apply CUG policy on /content/a. > ** Authorize user1 and user2 to read /content/a. > ** Authorize user1 to read /content/a/b1. > ** Authorize user2 to read /content/a/b2. > # Remove :nestedCugs property from /content/a/rep:cugPolicy. > # Create a content session, login with user2. Try to read /content/a/b1. > *Observed behavior* : user2 is able to read /content/a/b1. > *Expected behavior* : user2 should not be able to read /content/a/b1 as it is > unauthorized to do so. > Please note that :nestedCugs is removed by a mechanism which completely > overwrites content tree below "/content/a". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8855) Permission evaluation of nodes broken after :nestedCug removed from parent node
[ https://issues.apache.org/jira/browse/OAK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8855: - Affects Version/s: (was: 1.6.19) 1.8.7 > Permission evaluation of nodes broken after :nestedCug removed from parent > node > --- > > Key: OAK-8855 > URL: https://issues.apache.org/jira/browse/OAK-8855 > Project: Jackrabbit Oak > Issue Type: Bug > Components: authorization-cug >Affects Versions: 1.8.7 >Reporter: Kunal Shubham >Assignee: Andrei Dulceanu >Priority: Major > Attachments: 0001-Fix-nestedcug-permission-issue.patch > > > Steps to Reproduce: > # Create a node 'a' which has two children nodes 'b1' and 'b2'. The content > tree looks as shown: /content/a/b1, /content/a/b2. Create two users user1 and > user2. > # Apply CUG policy on /content/a. > ** Authorize user1 and user2 to read /content/a. > ** Authorize user1 to read /content/a/b1. > ** Authorize user2 to read /content/a/b2. > # Remove :nestedCugs property from /content/a/rep:cugPolicy. > # Create a content session, login with user2. Try to read /content/a/b1. > *Observed behavior* : user2 is able to read /content/a/b1. > *Expected behavior* : user2 should not be able to read /content/a/b1 as it is > unauthorized to do so. > Please note that :nestedCugs is removed by a mechanism which completely > overwrites content tree below "/content/a". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8855) Permission evaluation of nodes broken after :nestedCug removed from parent node
[
https://issues.apache.org/jira/browse/OAK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015808#comment-17015808
]
Andrei Dulceanu commented on OAK-8855:
--
[~kunal3112], I'm trying to apply your patch with {{patch -p0 < patch-file}},
but I run into errors. Can you please create another one by issuing the
following command from project parent dir (i.e. jackrabbit-oak)?
{noformat}
git diff --no-prefix upstream-trunk > OAK-8855.patch
{noformat}
> Permission evaluation of nodes broken after :nestedCug removed from parent
> node
> ---
>
> Key: OAK-8855
> URL: https://issues.apache.org/jira/browse/OAK-8855
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: authorization-cug
>Affects Versions: 1.8.7
>Reporter: Kunal Shubham
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: 0001-Fix-nestedcug-permission-issue.patch
>
>
> Steps to Reproduce:
> # Create a node 'a' which has two children nodes 'b1' and 'b2'. The content
> tree looks as shown: /content/a/b1, /content/a/b2. Create two users user1 and
> user2.
> # Apply CUG policy on /content/a.
> ** Authorize user1 and user2 to read /content/a.
> ** Authorize user1 to read /content/a/b1.
> ** Authorize user2 to read /content/a/b2.
> # Remove :nestedCugs property from /content/a/rep:cugPolicy.
> # Create a content session, login with user2. Try to read /content/a/b1.
> *Observed behavior* : user2 is able to read /content/a/b1.
> *Expected behavior* : user2 should not be able to read /content/a/b1 as it is
> unauthorized to do so.
> Please note that :nestedCugs is removed by a mechanism which completely
> overwrites content tree below "/content/a".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8855) Permission evaluation of nodes broken after :nestedCug removed from parent node
[
https://issues.apache.org/jira/browse/OAK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015919#comment-17015919
]
Andrei Dulceanu commented on OAK-8855:
--
[~kunal3112], Oak build fails with the following exception after applying the
patch on 1.8 local branch:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile
(default-testCompile) on project oak-authorization-cug: Compilation failure:
Compilation failure:
[ERROR]
/Users/dulceanu/projects/apache/jackrabbit-oak/oak-authorization-cug/src/test/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/impl/NestedCugHookPermissionTest.java:[89,9]
cannot find symbol
[ERROR] symbol: method
createTrees(org.apache.jackrabbit.oak.api.Tree,java.lang.String,java.lang.String,java.lang.String)
[ERROR] location: class
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.NestedCugHookPermissionTest
[ERROR]
/Users/dulceanu/projects/apache/jackrabbit-oak/oak-authorization-cug/src/test/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/impl/NestedCugHookPermissionTest.java:[90,9]
cannot find symbol
[ERROR] symbol: method
createTrees(org.apache.jackrabbit.oak.api.Tree,java.lang.String,java.lang.String,java.lang.String)
[ERROR] location: class
org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.NestedCugHookPermissionTest
{noformat}
Can you please add the missing method to a new patch?
> Permission evaluation of nodes broken after :nestedCug removed from parent
> node
> ---
>
> Key: OAK-8855
> URL: https://issues.apache.org/jira/browse/OAK-8855
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: authorization-cug
>Affects Versions: 1.8.7
>Reporter: Kunal Shubham
>Assignee: Andrei Dulceanu
>Priority: Major
> Attachments: 0001-Fix-nestedcug-permission-issue.patch,
> OAK-8855_backport.patch, diff.patch
>
>
> Steps to Reproduce:
> # Create a node 'a' which has two children nodes 'b1' and 'b2'. The content
> tree looks as shown: /content/a/b1, /content/a/b2. Create two users user1 and
> user2.
> # Apply CUG policy on /content/a.
> ** Authorize user1 and user2 to read /content/a.
> ** Authorize user1 to read /content/a/b1.
> ** Authorize user2 to read /content/a/b2.
> # Remove :nestedCugs property from /content/a/rep:cugPolicy.
> # Create a content session, login with user2. Try to read /content/a/b1.
> *Observed behavior* : user2 is able to read /content/a/b1.
> *Expected behavior* : user2 should not be able to read /content/a/b1 as it is
> unauthorized to do so.
> Please note that :nestedCugs is removed by a mechanism which completely
> overwrites content tree below "/content/a".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-8855) Permission evaluation of nodes broken after :nestedCug removed from parent node
[ https://issues.apache.org/jira/browse/OAK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-8855: Assignee: Angela Schreiber (was: Andrei Dulceanu) > Permission evaluation of nodes broken after :nestedCug removed from parent > node > --- > > Key: OAK-8855 > URL: https://issues.apache.org/jira/browse/OAK-8855 > Project: Jackrabbit Oak > Issue Type: Bug > Components: authorization-cug >Affects Versions: 1.8.7 >Reporter: Kunal Shubham >Assignee: Angela Schreiber >Priority: Major > Attachments: 0001-Fix-nestedcug-permission-issue.patch, > OAK-8855_backport.patch, diff.patch > > > Steps to Reproduce: > # Create a node 'a' which has two children nodes 'b1' and 'b2'. The content > tree looks as shown: /content/a/b1, /content/a/b2. Create two users user1 and > user2. > # Apply CUG policy on /content/a. > ** Authorize user1 and user2 to read /content/a. > ** Authorize user1 to read /content/a/b1. > ** Authorize user2 to read /content/a/b2. > # Remove :nestedCugs property from /content/a/rep:cugPolicy. > # Create a content session, login with user2. Try to read /content/a/b1. > *Observed behavior* : user2 is able to read /content/a/b1. > *Expected behavior* : user2 should not be able to read /content/a/b1 as it is > unauthorized to do so. > Please note that :nestedCugs is removed by a mechanism which completely > overwrites content tree below "/content/a". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8869) Access azure segments metadata in a case-insensitive way
[ https://issues.apache.org/jira/browse/OAK-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-8869: Assignee: Andrei Dulceanu > Access azure segments metadata in a case-insensitive way > > > Key: OAK-8869 > URL: https://issues.apache.org/jira/browse/OAK-8869 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure >Affects Versions: 1.8.19 >Reporter: Aravindo Wingeier >Assignee: Andrei Dulceanu >Priority: Major > Labels: azureblob > Attachments: OAK-8869-patch1.patch > > > We use azcopy to copy segments from one azure blob container to another for > testing. There is a bug in the current version of azcopy (10.3.3), which > makes all metadata keys start with a capital letter - "type" becomes "Type". > As a consequence, the current implementation can not find the segments in the > azure blob storage. > > The azcopy issue was already reported [1] in 2018. I have little hope that > azcopy will be fixed soon. > > Therefore I suggest a patch to oak-segment-azure, that would be backward > compatible and ignore the case of the keys when reading metadata. We should > be strict in what we write and tolerant in what we read. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8869) Access azure segments metadata in a case-insensitive way
[
https://issues.apache.org/jira/browse/OAK-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023100#comment-17023100
]
Andrei Dulceanu commented on OAK-8869:
--
[~wingeier] the patch looks good, thanks for the submission! Some small
nitpicking: would it make sense to rename {{CaseInsensitiveMapAccess}} to
something else, making it clear that actually the keys are treated in a
case-insensitive manner?
> Access azure segments metadata in a case-insensitive way
>
>
> Key: OAK-8869
> URL: https://issues.apache.org/jira/browse/OAK-8869
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure
>Affects Versions: 1.8.19
>Reporter: Aravindo Wingeier
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: azureblob
> Attachments: OAK-8869-patch1.patch
>
>
> We use azcopy to copy segments from one azure blob container to another for
> testing. There is a bug in the current version of azcopy (10.3.3), which
> makes all metadata keys start with a capital letter - "type" becomes "Type".
> As a consequence, the current implementation can not find the segments in the
> azure blob storage.
>
> The azcopy issue was already reported [1] in 2018. I have little hope that
> azcopy will be fixed soon.
>
> Therefore I suggest a patch to oak-segment-azure, that would be backward
> compatible and ignore the case of the keys when reading metadata. We should
> be strict in what we write and tolerant in what we read.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8869) Access azure segments metadata in a case-insensitive way
[ https://issues.apache.org/jira/browse/OAK-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024240#comment-17024240 ] Andrei Dulceanu commented on OAK-8869: -- [~wingeier], thanks for iterating over the patch! I committed the last version in trunk at r1873202. > Access azure segments metadata in a case-insensitive way > > > Key: OAK-8869 > URL: https://issues.apache.org/jira/browse/OAK-8869 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure >Affects Versions: 1.8.19 >Reporter: Aravindo Wingeier >Assignee: Andrei Dulceanu >Priority: Major > Labels: azureblob > Attachments: OAK-8869-patch1.patch, OAK-8869-patch2.patch, > OAK-8869-patch3.patch > > > We use azcopy to copy segments from one azure blob container to another for > testing. There is a bug in the current version of azcopy (10.3.3), which > makes all metadata keys start with a capital letter - "type" becomes "Type". > As a consequence, the current implementation can not find the segments in the > azure blob storage. > > The azcopy issue was already reported [1] in 2018. I have little hope that > azcopy will be fixed soon. > > Therefore I suggest a patch to oak-segment-azure, that would be backward > compatible and ignore the case of the keys when reading metadata. We should > be strict in what we write and tolerant in what we read. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8869) Access azure segments metadata in a case-insensitive way
[ https://issues.apache.org/jira/browse/OAK-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-8869. -- Fix Version/s: 1.26.0 Resolution: Fixed > Access azure segments metadata in a case-insensitive way > > > Key: OAK-8869 > URL: https://issues.apache.org/jira/browse/OAK-8869 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure >Affects Versions: 1.8.19 >Reporter: Aravindo Wingeier >Assignee: Andrei Dulceanu >Priority: Major > Labels: azureblob > Fix For: 1.26.0 > > Attachments: OAK-8869-patch1.patch, OAK-8869-patch2.patch, > OAK-8869-patch3.patch > > > We use azcopy to copy segments from one azure blob container to another for > testing. There is a bug in the current version of azcopy (10.3.3), which > makes all metadata keys start with a capital letter - "type" becomes "Type". > As a consequence, the current implementation can not find the segments in the > azure blob storage. > > The azcopy issue was already reported [1] in 2018. I have little hope that > azcopy will be fixed soon. > > Therefore I suggest a patch to oak-segment-azure, that would be backward > compatible and ignore the case of the keys when reading metadata. We should > be strict in what we write and tolerant in what we read. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8869) Access azure segments metadata in a case-insensitive way
[ https://issues.apache.org/jira/browse/OAK-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026568#comment-17026568 ] Andrei Dulceanu commented on OAK-8869: -- [~mreutegg], thanks for catching that! What should I have run in order to catch it myself? A simple clean install doesn't do the job... > Access azure segments metadata in a case-insensitive way > > > Key: OAK-8869 > URL: https://issues.apache.org/jira/browse/OAK-8869 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure >Affects Versions: 1.8.19 >Reporter: Aravindo Wingeier >Assignee: Andrei Dulceanu >Priority: Major > Labels: azureblob > Fix For: 1.26.0 > > Attachments: OAK-8869-patch1.patch, OAK-8869-patch2.patch, > OAK-8869-patch3.patch > > > We use azcopy to copy segments from one azure blob container to another for > testing. There is a bug in the current version of azcopy (10.3.3), which > makes all metadata keys start with a capital letter - "type" becomes "Type". > As a consequence, the current implementation can not find the segments in the > azure blob storage. > > The azcopy issue was already reported [1] in 2018. I have little hope that > azcopy will be fixed soon. > > Therefore I suggest a patch to oak-segment-azure, that would be backward > compatible and ignore the case of the keys when reading metadata. We should > be strict in what we write and tolerant in what we read. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8827) AWS support for segment-tar
[ https://issues.apache.org/jira/browse/OAK-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026819#comment-17026819 ] Andrei Dulceanu commented on OAK-8827: -- [~alvarorahul], is the branch you posted back in December the latest one? If not, could you please add the latest branch in a comment here? > AWS support for segment-tar > --- > > Key: OAK-8827 > URL: https://issues.apache.org/jira/browse/OAK-8827 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8889) NPE in the oak-run console az:*
[
https://issues.apache.org/jira/browse/OAK-8889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17027495#comment-17027495
]
Andrei Dulceanu commented on OAK-8889:
--
Thanks for the heads-up, [~tomek.rekawek] ;)
> NPE in the oak-run console az:*
> ---
>
> Key: OAK-8889
> URL: https://issues.apache.org/jira/browse/OAK-8889
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run, segment-azure
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.26.0
>
>
> The oak-run console can be used with the Azure Segment Store, by providing
> the {{az:}} URL and the secret in an env variable. However, it'll throw a
> NPE, because of the missing {{options.getTempDirectory()}} value in
> {{org.apache.jackrabbit.oak.run.cli.SegmentTarFixtureProvider#configureSegment}}.
> There's no way to set this value from command line options for {{oak-run
> console}}. We can create a temp directory in this case - it shouldn't be used
> anyway, that's just a requirement for creating the FileStore.
> //cc: [~adulceanu]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8827) AWS support for segment-tar
[ https://issues.apache.org/jira/browse/OAK-8827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17028978#comment-17028978 ] Andrei Dulceanu commented on OAK-8827: -- Thanks for confirming, [~alvarorahul]! I am now taking a look at it :) > AWS support for segment-tar > --- > > Key: OAK-8827 > URL: https://issues.apache.org/jira/browse/OAK-8827 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8837) Refactor FileStore to support pluggable Compactor
[ https://issues.apache.org/jira/browse/OAK-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-8837: - Attachment: OAK-8837.patch > Refactor FileStore to support pluggable Compactor > - > > Key: OAK-8837 > URL: https://issues.apache.org/jira/browse/OAK-8837 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8837.patch > > > In our current implementation it is hard to switch the compactor "flavour" > because the actual compactor implementation is hidden under many indirection > layers of strategies. We need a quick workaround to support the use-case from > OAK-8836, i.e. allowing tooling to change at runtime the default compactor > implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8837) Refactor FileStore to support pluggable Compactor
[ https://issues.apache.org/jira/browse/OAK-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074567#comment-17074567 ] Andrei Dulceanu commented on OAK-8837: -- Fixed in trunk at r1876087. /cc [~tomekr] > Refactor FileStore to support pluggable Compactor > - > > Key: OAK-8837 > URL: https://issues.apache.org/jira/browse/OAK-8837 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Attachments: OAK-8837.patch > > > In our current implementation it is hard to switch the compactor "flavour" > because the actual compactor implementation is hidden under many indirection > layers of strategies. We need a quick workaround to support the use-case from > OAK-8836, i.e. allowing tooling to change at runtime the default compactor > implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8837) Refactor FileStore to support pluggable Compactor
[ https://issues.apache.org/jira/browse/OAK-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-8837. -- Fix Version/s: 1.28.0 Resolution: Fixed > Refactor FileStore to support pluggable Compactor > - > > Key: OAK-8837 > URL: https://issues.apache.org/jira/browse/OAK-8837 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.28.0 > > Attachments: OAK-8837.patch > > > In our current implementation it is hard to switch the compactor "flavour" > because the actual compactor implementation is hidden under many indirection > layers of strategies. We need a quick workaround to support the use-case from > OAK-8836, i.e. allowing tooling to change at runtime the default compactor > implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8836) oak-run compact should offer the possibility to choose between checkpoints compactor and the classical compactor
[
https://issues.apache.org/jira/browse/OAK-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8836:
-
Description:
Until the final fix for OAK-8832 will be out and even after that, I think we
must offer the possibility to do offline compaction in two modes:
* current optimized solution which compacts checkpoints on top of the other,
chronologically and after that the root state on top of those
* previous un-optimized solution which blindly compacts everything, making use
of the deduplication caches to control checkpoints "explosion"
I propose to add an optional argument to compact, {{--compactor}} with three
values: auto, diff and classic. When not set, it will just go with whatever we
choose as auto - for now "classic". If set, it will use the mode provided.
was:
Until the final fix for OAK-8832 will be out and even after that, I think we
must offer the possibility to do offline compaction in two modes:
* current optimized solution which compacts checkpoints on top of the other,
chronologically and after that the root state on top of those
* previous un-optimized solution which blindly compacts everything, making use
of the deduplication caches to control checkpoints "explosion"
I propose to add an optional argument to compact, {{--mode}} with three values:
auto, diff and classic. When not set, it will just go with whatever we choose
as auto - for now "classic". If set, it will use the mode provided.
> oak-run compact should offer the possibility to choose between checkpoints
> compactor and the classical compactor
>
>
> Key: OAK-8836
> URL: https://issues.apache.org/jira/browse/OAK-8836
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> Until the final fix for OAK-8832 will be out and even after that, I think we
> must offer the possibility to do offline compaction in two modes:
> * current optimized solution which compacts checkpoints on top of the other,
> chronologically and after that the root state on top of those
> * previous un-optimized solution which blindly compacts everything, making
> use of the deduplication caches to control checkpoints "explosion"
> I propose to add an optional argument to compact, {{--compactor}} with three
> values: auto, diff and classic. When not set, it will just go with whatever
> we choose as auto - for now "classic". If set, it will use the mode provided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8836) oak-run compact should offer the possibility to choose between checkpoints compactor and the classical compactor
[
https://issues.apache.org/jira/browse/OAK-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8836.
--
Resolution: Fixed
Fixed in trunk at r1876227.
> oak-run compact should offer the possibility to choose between checkpoints
> compactor and the classical compactor
>
>
> Key: OAK-8836
> URL: https://issues.apache.org/jira/browse/OAK-8836
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> Until the final fix for OAK-8832 will be out and even after that, I think we
> must offer the possibility to do offline compaction in two modes:
> * current optimized solution which compacts checkpoints on top of the other,
> chronologically and after that the root state on top of those
> * previous un-optimized solution which blindly compacts everything, making
> use of the deduplication caches to control checkpoints "explosion"
> I propose to add an optional argument to compact, {{--compactor}} with three
> values: auto, diff and classic. When not set, it will just go with whatever
> we choose as auto - for now "classic". If set, it will use the mode provided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
[ https://issues.apache.org/jira/browse/OAK-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu closed OAK-8969. > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set > -- > > Key: OAK-8969 > URL: https://issues.apache.org/jira/browse/OAK-8969 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-cloud-azure >Affects Versions: 1.26.0 >Reporter: Jun Zhang >Assignee: Matt Ryan >Priority: Major > Fix For: 1.22.3, 1.28.0 > > > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OAK-8978) Cache facet results
[ https://issues.apache.org/jira/browse/OAK-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu closed OAK-8978. > Cache facet results > --- > > Key: OAK-8978 > URL: https://issues.apache.org/jira/browse/OAK-8978 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.22.3, 1.28.0 > > Attachments: OAK-8978-2.patch > > > In OAK-8898, the "AlreadyClosedException" was fixed when reading facet > results. > If the facets are read repeatedly (for each row), then the reader is now > opened and closed each time. This can slow down the application. > It should be possible to cache the facet result in DelayedLuceneFacetProvider -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OAK-8935) Improve ClusterNodeInfo MAC address detection
[ https://issues.apache.org/jira/browse/OAK-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu closed OAK-8935. > Improve ClusterNodeInfo MAC address detection > -- > > Key: OAK-8935 > URL: https://issues.apache.org/jira/browse/OAK-8935 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Affects Versions: 1.12.0 >Reporter: Jorge Flórez >Assignee: Julian Reschke >Priority: Major > Labels: candidate_oak_1_8 > Fix For: 1.22.3, 1.28.0 > > Attachments: OAK-8935.diff > > > ClusterNodeInfo is taking the lowest MAC address found in the machine. When > the machine has "docker0" bridge, it takes that MAC address (which may > change) and uses it. Resulting in errors like this one: > Configured cluster node id 123 already in use: needs recovery and > machineId/instanceId do not match: mac:02421b0c73d3//home/ec2-user != > mac:0242a5c0c5e5//home/ec2-user -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OAK-8898) On querying, IndexReader failed with AlreadyClosedException
[
https://issues.apache.org/jira/browse/OAK-8898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu closed OAK-8898.
> On querying, IndexReader failed with AlreadyClosedException
> ---
>
> Key: OAK-8898
> URL: https://issues.apache.org/jira/browse/OAK-8898
> Project: Jackrabbit Oak
> Issue Type: Bug
>Reporter: Mohit Kataria
>Assignee: Mohit Kataria
>Priority: Major
> Fix For: 1.26.0, 1.22.3
>
> Attachments: OAK-8898-1.10.8.patch
>
>
> This is an intermittent issue, where on querying the code throws
> AlreadyClosedException.
>
> {code:java}
> Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexReader
> is closed
> at org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:262)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.lucene.index.BaseCompositeReader.document(BaseCompositeReader.java:108)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at org.apache.lucene.index.IndexReader.document(IndexReader.java:446)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.util.StatisticalSortedSetDocValuesFacetCounts.getAccessibleSampleCount(StatisticalSortedSetDocValuesFacetCounts.java:169)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.util.StatisticalSortedSetDocValuesFacetCounts.getTopChildren0(StatisticalSortedSetDocValuesFacetCounts.java:104)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.util.StatisticalSortedSetDocValuesFacetCounts.getTopChildren(StatisticalSortedSetDocValuesFacetCounts.java:70)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.lucene.facet.MultiFacets.getTopChildren(MultiFacets.java:52)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LuceneFacetProvider.getFacets(LucenePropertyIndex.java:1547)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.query.FulltextIndex$FulltextResultRow.getFacets(FulltextIndex.java:353)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> at
> org.apache.jackrabbit.oak.plugins.index.search.spi.query.FulltextIndex$FulltextPathCursor$2.getValue(FulltextIndex.java:472)
> [org.apache.jackrabbit.oak-lucene:1.10.2]
> ... 237 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8967) OR query with ORDER BY don't work as expected
[ https://issues.apache.org/jira/browse/OAK-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu closed OAK-8967. > OR query with ORDER BY don't work as expected > -- > > Key: OAK-8967 > URL: https://issues.apache.org/jira/browse/OAK-8967 > Project: Jackrabbit Oak > Issue Type: Bug > Components: search >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > Labels: candidate_oak_1_8 > Fix For: 1.22.3, 1.28.0 > > > A query with Or and having order by along with limit Don't reproduce results > as per order mentioned. > e.g. > Let content be: > "/UnionQueryTest1/node0", > "/UnionQueryTest/node0", > "/UnionQueryTest1/node0/node1", > "/UnionQueryTest/node0/node1", > "/UnionQueryTest1/node0/node1/node2", > "/UnionQueryTest/node0/node1/node2", > "/UnionQueryTest1/node0/node1/node2/node3", > "/UnionQueryTest/node0/node1/node2/node3" > each node having x = number in node name. > SELECT idn1.* FROM [nt:base] as idn1 WHERE > ISDESCENDANTNODE([/UnionQueryTest]) OR ISDESCENDANTNODE([/UnionQueryTest1]) > ORDER BY idn1.[x] ASC > > result should be same as above mentioned where as current result come out to > be > /UnionQueryTest1/node0 > /UnionQueryTest1/node0/node1 > /UnionQueryTest1/node0/node1/node2 > /UnionQueryTest1/node0/node1/node2/node3 > /UnionQueryTest1/node0/node1/node2/node3/node4 > /UnionQueryTest/node0 > /UnionQueryTest/node0/node1 > /UnionQueryTest/node0/node1/node2 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8832:
-
Attachment: OAK-8832.patch
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.10.0, 1.12.0, 1.8.11, 1.14.0, 1.16.0, 1.18.0, 1.20.0,
> 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Attachments: OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)
> at
> org.apache.jackrabbit.oak.segmen
[jira] [Commented] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090612#comment-17090612
]
Andrei Dulceanu commented on OAK-8832:
--
[~amjain], what do you think about the proposed patch?
To give you a bit of context, we are seeing this on offline compaction only
(which doesn't use a blob store at runtime). The strategy used by checkpoints
compactor is to compact the oldest checkpoint and then each subsequent
checkpoint and the root state *on top of what was previously compacted*. In
case of external blobs which changed in the root state {{SegmentBlob#equals}}
is called, which in turn uses {{SegmentBlob#length}} to short circuit the
comparison in case of different lengths. However, the latter attempts to
compute the length by actually retrieving the blob from the blob store, hence
the error message.
Reading the comments from OAK-5253, I know that in the past you suggested using
the blob content identity to optimize {{AbstractBlob#equal}}. Although I
understood the concerns raised there, it seems to me that we can still apply
the attached patch given its limited scope and use case (the short circuit
based on content identity will happen only if the blob store is not configured).
Let me know your thoughts. Thanks!
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.10.0, 1.12.0, 1.8.11, 1.14.0, 1.16.0, 1.18.0, 1.20.0,
> 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Attachments: OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor
[jira] [Updated] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8832:
-
Attachment: OAK-8832-test.patch
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.10.0, 1.12.0, 1.8.11, 1.14.0, 1.16.0, 1.18.0, 1.20.0,
> 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Attachments: OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)
> at
> org.ap
[jira] [Updated] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8832:
-
Affects Version/s: (was: 1.20.0)
(was: 1.18.0)
(was: 1.16.0)
(was: 1.14.0)
(was: 1.12.0)
(was: 1.10.0)
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Attachments: OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segm
[jira] [Updated] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8832:
-
Attachment: OAK-8832-02.patch
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)
> at
> org.apache.jackrabbit.oak.segment.MapRec
[jira] [Commented] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093340#comment-17093340
]
Andrei Dulceanu commented on OAK-8832:
--
Thanks for reviewing, [~amjain]! I committed a slightly modified version of the
patch, [^OAK-8832-02.patch], which returns earlier from #equals in case one of
the binaries is external and the other is inlined.
Fixed in trunk at r1877063.
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNod
[jira] [Resolved] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-8832.
--
Resolution: Fixed
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Fix For: 1.28.0, 1.8.22, 1.22.4
>
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)
> at
> or
[jira] [Updated] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8832:
-
Fix Version/s: 1.22.4
1.8.22
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Fix For: 1.28.0, 1.8.22, 1.22.4
>
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecor
[jira] [Comment Edited] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093350#comment-17093350
]
Andrei Dulceanu edited comment on OAK-8832 at 4/28/20, 11:46 AM:
-
trunk: [r1877064|http://svn.apache.org/r1877064]
[r1877063|http://svn.apache.org/r1877063]
1.22: [r1877129|http://svn.apache.org/viewvc?view=revision&revision=1877129]
1.8: [r1877086|http://svn.apache.org/r1877086]
[r1877083|http://svn.apache.org/r1877083]
was (Author: reschke):
trunk: [r1877064|http://svn.apache.org/r1877064]
[r1877063|http://svn.apache.org/r1877063]
1.22:
1.8: [r1877086|http://svn.apache.org/r1877086]
[r1877083|http://svn.apache.org/r1877083]
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Fix For: 1.28.0
>
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.
[jira] [Assigned] (OAK-9042) Improve azure archive recovery during startup
[ https://issues.apache.org/jira/browse/OAK-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-9042: Assignee: Andrei Dulceanu > Improve azure archive recovery during startup > - > > Key: OAK-9042 > URL: https://issues.apache.org/jira/browse/OAK-9042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure, segment-tar >Affects Versions: 1.26.0 >Reporter: Miroslav Smiljanic >Assignee: Andrei Dulceanu >Priority: Major > Labels: Patch > Attachments: proposal.patch > > > During repository startup if archive directory is not closed properly, > recovery will be performed. During that procedure, segents are copied to the > backup directory and deleted from the source direcory, one by one. > It can create problems and negativelly impact other ongoing actiivties, which > are accessing the same archive. This activity, for example, can be repository > cloning in order to create new environment. > Proposed patch, after creating backup is not deleting all segments from > archive, but only segments which could not be recovered. > [^proposal.patch] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8988) TarPersistence.lockRepostiory can indefinitely wait if another external process already running
[
https://issues.apache.org/jira/browse/OAK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095424#comment-17095424
]
Andrei Dulceanu commented on OAK-8988:
--
[~amitj], looking at {{lockFile.getChannel().lock()}} it appears that this
method can throw an {{OverlappingFileLockException}}, " If a lock that overlaps
the requested region is already held by this Java virtual machine, or if
another thread is already blocked in this method and is attempting to lock an
overlapping region of the same file".
I assume in such a case acquiring the lock will fail fast with
{{IllegalStateException}}.
> TarPersistence.lockRepostiory can indefinitely wait if another external
> process already running
> ---
>
> Key: OAK-8988
> URL: https://issues.apache.org/jira/browse/OAK-8988
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Reporter: Amit Jain
>Priority: Major
>
> TarPersistence.lockRepostiory() [1] waits indefinitely when another segment
> tar process is already running and has acquired the lock already. The method
> should timeout if it fails to obtain a lock in a reasonable time (can be an
> internal value) or have alternative means ascertaining that another process
> already running e.g. by using mkdir().
> 1 -
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/tar/TarPersistence.java#L92-L103|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/tar/TarPersistence.java#L92-L103]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-9042) Improve azure archive recovery during startup
[ https://issues.apache.org/jira/browse/OAK-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-9042. -- Fix Version/s: 1.28.0 Resolution: Fixed > Improve azure archive recovery during startup > - > > Key: OAK-9042 > URL: https://issues.apache.org/jira/browse/OAK-9042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure, segment-tar >Affects Versions: 1.26.0 >Reporter: Miroslav Smiljanic >Assignee: Andrei Dulceanu >Priority: Major > Labels: Patch > Fix For: 1.28.0 > > Attachments: proposal.patch, test_tar_repo_recovery.patch > > > During repository startup if archive directory is not closed properly, > recovery will be performed. During that procedure, segents are copied to the > backup directory and deleted from the source direcory, one by one. > It can create problems and negativelly impact other ongoing actiivties, which > are accessing the same archive. This activity, for example, can be repository > cloning in order to create new environment. > Proposed patch, after creating backup is not deleting all segments from > archive, but only segments which could not be recovered. > [^proposal.patch] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9042) Improve azure archive recovery during startup
[ https://issues.apache.org/jira/browse/OAK-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096344#comment-17096344 ] Andrei Dulceanu commented on OAK-9042: -- Fixed in trunk at r1877193. Thanks for the contribution, [~smiroslav]! > Improve azure archive recovery during startup > - > > Key: OAK-9042 > URL: https://issues.apache.org/jira/browse/OAK-9042 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-azure, segment-tar >Affects Versions: 1.26.0 >Reporter: Miroslav Smiljanic >Assignee: Andrei Dulceanu >Priority: Major > Labels: Patch > Attachments: proposal.patch, test_tar_repo_recovery.patch > > > During repository startup if archive directory is not closed properly, > recovery will be performed. During that procedure, segents are copied to the > backup directory and deleted from the source direcory, one by one. > It can create problems and negativelly impact other ongoing actiivties, which > are accessing the same archive. This activity, for example, can be repository > cloning in order to create new environment. > Proposed patch, after creating backup is not deleting all segments from > archive, but only segments which could not be recovered. > [^proposal.patch] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-8832:
-
Fix Version/s: 1.10.9
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Fix For: 1.10.9, 1.28.0, 1.8.22, 1.22.4
>
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:408)
> at
> org.apache.jackrabbit.oak.segment.MapRecord$4.childNodeChanged(MapRecord.java:449)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:495)
>
[jira] [Comment Edited] (OAK-8832) Offline Compaction fails while erroneously accessing external blob
[
https://issues.apache.org/jira/browse/OAK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093350#comment-17093350
]
Andrei Dulceanu edited comment on OAK-8832 at 5/7/20, 10:56 AM:
trunk: [r1877064|http://svn.apache.org/r1877064]
[r1877063|http://svn.apache.org/r1877063]
1.22: [r1877189|http://svn.apache.org/r1877189]
[r1877129|http://svn.apache.org/r1877129]
1.8: [r1877086|http://svn.apache.org/r1877086]
[r1877083|http://svn.apache.org/r1877083]
1.10: [r1877469|http://svn.apache.org/r1877469]
was (Author: reschke):
trunk: [r1877064|http://svn.apache.org/r1877064]
[r1877063|http://svn.apache.org/r1877063]
1.22: [r1877189|http://svn.apache.org/r1877189]
[r1877129|http://svn.apache.org/r1877129]
1.8: [r1877086|http://svn.apache.org/r1877086]
[r1877083|http://svn.apache.org/r1877083]
> Offline Compaction fails while erroneously accessing external blob
> ---
>
> Key: OAK-8832
> URL: https://issues.apache.org/jira/browse/OAK-8832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.8.11, 1.22.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Critical
> Fix For: 1.10.9, 1.28.0, 1.8.22, 1.22.4
>
> Attachments: OAK-8832-02.patch, OAK-8832-test.patch, OAK-8832.patch
>
>
> Relevant stack trace:
> {noformat}
> INFO [2019-12-06 01:07:39,345]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK GC #0: compacting
> root.
> java.lang.IllegalStateException: Attempt to read external blob with blobId
> [95c88847bd388c05fc332e737dda714630c11351d1949ffd1a03b7b09b92d1ea#71399]
> without specifying BlobStore
> INFO [2019-12-06 01:07:39,753]
> org.apache.jackrabbit.oak.segment.file.FileStore: TarMK closed:
> /mnt/sandbox/tmp/1575594001228-0
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getBlob(SegmentBlob.java:248)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.getLength(SegmentBlob.java:257)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.length(SegmentBlob.java:109)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.equals(SegmentBlob.java:185)
> at com.google.common.base.Objects.equal(Objects.java:52)
> at
> org.apache.jackrabbit.oak.plugins.memory.AbstractPropertyState.equal(AbstractPropertyState.java:59)
> at
> org.apache.jackrabbit.oak.segment.SegmentPropertyState.equals(SegmentPropertyState.java:249)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareProperties(SegmentNodeState.java:664)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:558)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:598)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:422)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:651)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.diff(Compactor.java:165)
> at
> org.apache.jackrabbit.oak.segment.Compactor.compact(Compactor.java:123)
> at
> org.apache.jackrabbit.oak.segment.Compactor$CompactDiff.childNodeChanged(Compactor.java:217)
> at
> org.apache.jackrabbit.oak.segment.CancelableDiff.childNodeChanged(CancelableDiff.java:85)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(S
