[jira] [Resolved] (OAK-10978) Skip Azure compaction when there's not enough garbage in the repository
[ https://issues.apache.org/jira/browse/OAK-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10978. --- Fix Version/s: 1.68.0 Resolution: Fixed > Skip Azure compaction when there's not enough garbage in the repository > --- > > Key: OAK-10978 > URL: https://issues.apache.org/jira/browse/OAK-10978 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Minor > Fix For: 1.68.0 > > > We can have a simple estimation based on current repository size vs. last > repository size (if available in gc.log) as online compaction is doing and > skip compaction if the garbage in the repository is below a certain threshold > (e.g. 1 GB) or a certain percentage (e.g. 10%). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10978) Skip Azure compaction when there's not enough garbage in the repository
Andrei Dulceanu created OAK-10978: - Summary: Skip Azure compaction when there's not enough garbage in the repository Key: OAK-10978 URL: https://issues.apache.org/jira/browse/OAK-10978 Project: Jackrabbit Oak Issue Type: Story Components: oak-run, segment-azure Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu We can have a simple estimation based on current repository size vs. last repository size (if available in gc.log) as online compaction is doing and skip compaction if the garbage in the repository is below a certain threshold (e.g. 1 GB) or a certain percentage (e.g. 10%). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10917) Make persistent cache related arguments optional for Azure compaction
[
https://issues.apache.org/jira/browse/OAK-10917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10917.
---
Fix Version/s: 1.66.0
Resolution: Fixed
> Make persistent cache related arguments optional for Azure compaction
> -
>
> Key: OAK-10917
> URL: https://issues.apache.org/jira/browse/OAK-10917
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: run, segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.66.0
>
>
> At the moment both {{persistent-cache-path}} and {{persistent-cache-size-gb}}
> are required arguments for running Azure compaction, although it should be
> possible to run it without the persistent cache.
> The goal is to make those two optional and to update the documentation
> accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10917) Make persistent cache related arguments optional for Azure compaction
Andrei Dulceanu created OAK-10917:
-
Summary: Make persistent cache related arguments optional for
Azure compaction
Key: OAK-10917
URL: https://issues.apache.org/jira/browse/OAK-10917
Project: Jackrabbit Oak
Issue Type: Task
Components: run, segment-azure
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
At the moment both {{persistent-cache-path}} and {{persistent-cache-size-gb}}
are required arguments for running Azure compaction, although it should be
possible to run it without the persistent cache.
The goal is to make those two optional and to update the documentation
accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10898) Allow AzureCheck and AzureCompact to be built directly with a CloudBlobDirectory
[
https://issues.apache.org/jira/browse/OAK-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10898.
---
Resolution: Fixed
> Allow AzureCheck and AzureCompact to be built directly with a
> CloudBlobDirectory
>
>
> Key: OAK-10898
> URL: https://issues.apache.org/jira/browse/OAK-10898
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.66.0
>
>
> Sometimes if we want to run both {{AzureCompact}} or {{AzureCheck}} from a
> Java process, there's a problem with setting the {{AZURE_SECRET_KEY}}
> environment variable necessary for connecting to Azure.
> It should be possible to allow both classes to be built directly with a
> {{CloudBlobDirectory}} instance, avoiding thus the need for an environment
> variable or for using the connection string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10898) Allow AzureCheck and AzureCompact to be built directly with a CloudBlobDirectory
[
https://issues.apache.org/jira/browse/OAK-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856498#comment-17856498
]
Andrei Dulceanu commented on OAK-10898:
---
[~reschke], I re-opened it since I realized I forgot to address some details. I
will set it to fixed after my next commit.
> Allow AzureCheck and AzureCompact to be built directly with a
> CloudBlobDirectory
>
>
> Key: OAK-10898
> URL: https://issues.apache.org/jira/browse/OAK-10898
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.66.0
>
>
> Sometimes if we want to run both {{AzureCompact}} or {{AzureCheck}} from a
> Java process, there's a problem with setting the {{AZURE_SECRET_KEY}}
> environment variable necessary for connecting to Azure.
> It should be possible to allow both classes to be built directly with a
> {{CloudBlobDirectory}} instance, avoiding thus the need for an environment
> variable or for using the connection string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (OAK-10898) Allow AzureCheck and AzureCompact to be built directly with a CloudBlobDirectory
[
https://issues.apache.org/jira/browse/OAK-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reopened OAK-10898:
---
> Allow AzureCheck and AzureCompact to be built directly with a
> CloudBlobDirectory
>
>
> Key: OAK-10898
> URL: https://issues.apache.org/jira/browse/OAK-10898
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.66.0
>
>
> Sometimes if we want to run both {{AzureCompact}} or {{AzureCheck}} from a
> Java process, there's a problem with setting the {{AZURE_SECRET_KEY}}
> environment variable necessary for connecting to Azure.
> It should be possible to allow both classes to be built directly with a
> {{CloudBlobDirectory}} instance, avoiding thus the need for an environment
> variable or for using the connection string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10898) Allow AzureCheck and AzureCompact to be built directly with a CloudBlobDirectory
[
https://issues.apache.org/jira/browse/OAK-10898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10898.
---
Fix Version/s: 1.66.0
Resolution: Fixed
> Allow AzureCheck and AzureCompact to be built directly with a
> CloudBlobDirectory
>
>
> Key: OAK-10898
> URL: https://issues.apache.org/jira/browse/OAK-10898
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.66.0
>
>
> Sometimes if we want to run both {{AzureCompact}} or {{AzureCheck}} from a
> Java process, there's a problem with setting the {{AZURE_SECRET_KEY}}
> environment variable necessary for connecting to Azure.
> It should be possible to allow both classes to be built directly with a
> {{CloudBlobDirectory}} instance, avoiding thus the need for an environment
> variable or for using the connection string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10898) Allow AzureCheck and AzureCompact to be built directly with a CloudBlobDirectory
Andrei Dulceanu created OAK-10898:
-
Summary: Allow AzureCheck and AzureCompact to be built directly
with a CloudBlobDirectory
Key: OAK-10898
URL: https://issues.apache.org/jira/browse/OAK-10898
Project: Jackrabbit Oak
Issue Type: Task
Components: segment-azure, segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Sometimes if we want to run both {{AzureCompact}} or {{AzureCheck}} from a Java
process, there's a problem with setting the {{AZURE_SECRET_KEY}} environment
variable necessary for connecting to Azure.
It should be possible to allow both classes to be built directly with a
{{CloudBlobDirectory}} instance, avoiding thus the need for an environment
variable or for using the connection string.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10857) Improve oak-run to support unreferenced checkpoints removal for Azure repositories
[ https://issues.apache.org/jira/browse/OAK-10857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10857. --- Fix Version/s: 1.66.0 Resolution: Won't Do Fixing as Won't Do since removing the checkpoints on a running remote repository would need exclusive write access which cannot be obtained. > Improve oak-run to support unreferenced checkpoints removal for Azure > repositories > -- > > Key: OAK-10857 > URL: https://issues.apache.org/jira/browse/OAK-10857 > Project: Jackrabbit Oak > Issue Type: Task > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Minor > Fix For: 1.66.0 > > > It would be nice to have the same functionality for Azure repositories, as > removing unreferenced checkpoints could have a big impact on consistency > check and compaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10857) Improve oak-run to support unreferenced checkpoints removal for Azure repositories
[ https://issues.apache.org/jira/browse/OAK-10857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10857: -- Summary: Improve oak-run to support unreferenced checkpoints removal for Azure repositories (was: Improve oak-run to remove unreferenced checkpoints before compacting on Azure repositories) > Improve oak-run to support unreferenced checkpoints removal for Azure > repositories > -- > > Key: OAK-10857 > URL: https://issues.apache.org/jira/browse/OAK-10857 > Project: Jackrabbit Oak > Issue Type: Task > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Minor > > It would be nice to have the same functionality for Azure repositories, as > removing unreferenced checkpoints could have a big impact on consistency > check and compaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10857) Improve oak-run to remove unreferenced checkpoints before compacting on Azure repositories
Andrei Dulceanu created OAK-10857: - Summary: Improve oak-run to remove unreferenced checkpoints before compacting on Azure repositories Key: OAK-10857 URL: https://issues.apache.org/jira/browse/OAK-10857 Project: Jackrabbit Oak Issue Type: Task Components: oak-run, segment-azure Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu It would be nice to have the same functionality for Azure repositories, as removing unreferenced checkpoints could have a big impact on consistency check and compaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10807) Add oak-run diff to Azure repositories
[ https://issues.apache.org/jira/browse/OAK-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10807. --- Fix Version/s: 1.66.0 Resolution: Fixed > Add oak-run diff to Azure repositories > -- > > Key: OAK-10807 > URL: https://issues.apache.org/jira/browse/OAK-10807 > Project: Jackrabbit Oak > Issue Type: Story >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.66.0 > > > Currently oak-run diff is supported for TAR repositories only. This story is > about adding the same functionality to Azure repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10781) Access Token refresh in oak-blob-cloud-azure
[ https://issues.apache.org/jira/browse/OAK-10781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10781. --- Fix Version/s: 1.66.0 Resolution: Fixed > Access Token refresh in oak-blob-cloud-azure > > > Key: OAK-10781 > URL: https://issues.apache.org/jira/browse/OAK-10781 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Mohit Kataria >Priority: Major > Fix For: 1.66.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10833) Consistency check reports success for repository with SNFE in checkpoints
[
https://issues.apache.org/jira/browse/OAK-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10833.
---
Fix Version/s: 1.66.0
Resolution: Fixed
> Consistency check reports success for repository with SNFE in checkpoints
> -
>
> Key: OAK-10833
> URL: https://issues.apache.org/jira/browse/OAK-10833
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.64.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.66.0
>
>
> Excerpt from the erroneous run ({*}failFast{*} option used):
> {noformat}
> Checking /
> Error while traversing /oak:index: Segment
> 53095175-d0e3-4d30-a949-e88ec3175c9c not found
> Checked 1,129 nodes and 3,997 properties
> Checking checkpoint ed24479d-6f98-48af-9679-e7191a2a3765
> Checking /
> Error while traversing /oak:index: Segment
> 53095175-d0e3-4d30-a949-e88ec3175c9c not found
> Checked 1,129 nodes and 3,997 properties
> Checking checkpoint ffeac5ee-85b8-4262-b179-333737015acd
> Checking /
> Checked 4,314,103 nodes and 27,271,618 properties
> Path / is consistent
> Searched through 1 revisions and 3 checkpoints
> Head
> Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46
> from Mar 21, 2024, 11:40:46 AM
> Checkpoints
> - 9b2d7ef8-12ec-4281-8915-34ef5d4413b1
> Latest good revision for path / is none from unknown time
> - ed24479d-6f98-48af-9679-e7191a2a3765
> Latest good revision for path / is none from unknown time
> - ffeac5ee-85b8-4262-b179-333737015acd
> Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46
> Overall
> Latest good revision for paths and checkpoints checked is none from unknown
> time
> TarMK closed {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10807) Add oak-run diff to Azure repositories
[
https://issues.apache.org/jira/browse/OAK-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10807:
--
Description: Currently oak-run diff is supported for TAR repositories only.
This story is about adding the same functionality to Azure repositories. (was:
Currently {{FileStoreBuilder}} accepts only {{File}} path arguments in its
constructor making it impossible to use for {{oak-run}} tooling for remote
repositories. It should accept {{{}URI{}}}s as well, creating by default Azure
persistence backends.)
> Add oak-run diff to Azure repositories
> --
>
> Key: OAK-10807
> URL: https://issues.apache.org/jira/browse/OAK-10807
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> Currently oak-run diff is supported for TAR repositories only. This story is
> about adding the same functionality to Azure repositories.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10807) Add oak-run diff to Azure repositories
[
https://issues.apache.org/jira/browse/OAK-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10807:
--
Summary: Add oak-run diff to Azure repositories (was: Improve
FileStoreBuilder to accept URIs for remote repositories)
> Add oak-run diff to Azure repositories
> --
>
> Key: OAK-10807
> URL: https://issues.apache.org/jira/browse/OAK-10807
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> Currently {{FileStoreBuilder}} accepts only {{File}} path arguments in its
> constructor making it impossible to use for {{oak-run}} tooling for remote
> repositories. It should accept {{{}URI{}}}s as well, creating by default
> Azure persistence backends.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10833) Consistency check reports success for repository with SNFE in checkpoints
[
https://issues.apache.org/jira/browse/OAK-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10833:
--
Description:
Excerpt from the erroneous run ({*}failFast{*} option used):
{noformat}
Checking /
Error while traversing /oak:index: Segment 53095175-d0e3-4d30-a949-e88ec3175c9c
not found
Checked 1,129 nodes and 3,997 properties
Checking checkpoint ed24479d-6f98-48af-9679-e7191a2a3765
Checking /
Error while traversing /oak:index: Segment 53095175-d0e3-4d30-a949-e88ec3175c9c
not found
Checked 1,129 nodes and 3,997 properties
Checking checkpoint ffeac5ee-85b8-4262-b179-333737015acd
Checking /
Checked 4,314,103 nodes and 27,271,618 properties
Path / is consistent
Searched through 1 revisions and 3 checkpoints
Head
Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46 from
Mar 21, 2024, 11:40:46 AM
Checkpoints
- 9b2d7ef8-12ec-4281-8915-34ef5d4413b1
Latest good revision for path / is none from unknown time
- ed24479d-6f98-48af-9679-e7191a2a3765
Latest good revision for path / is none from unknown time
- ffeac5ee-85b8-4262-b179-333737015acd
Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46
Overall
Latest good revision for paths and checkpoints checked is none from unknown
time
TarMK closed {noformat}
was:
Excerpt from the erroneous run:
{noformat}
Checking /
Error while traversing /oak:index: Segment 53095175-d0e3-4d30-a949-e88ec3175c9c
not found
Checked 1,129 nodes and 3,997 properties
Checking checkpoint ed24479d-6f98-48af-9679-e7191a2a3765
Checking /
Error while traversing /oak:index: Segment 53095175-d0e3-4d30-a949-e88ec3175c9c
not found
Checked 1,129 nodes and 3,997 properties
Checking checkpoint ffeac5ee-85b8-4262-b179-333737015acd
Checking /
Checked 4,314,103 nodes and 27,271,618 properties
Path / is consistent
Searched through 1 revisions and 3 checkpoints
Head
Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46 from
Mar 21, 2024, 11:40:46 AM
Checkpoints
- 9b2d7ef8-12ec-4281-8915-34ef5d4413b1
Latest good revision for path / is none from unknown time
- ed24479d-6f98-48af-9679-e7191a2a3765
Latest good revision for path / is none from unknown time
- ffeac5ee-85b8-4262-b179-333737015acd
Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46
Overall
Latest good revision for paths and checkpoints checked is none from unknown
time
TarMK closed {noformat}
> Consistency check reports success for repository with SNFE in checkpoints
> -
>
> Key: OAK-10833
> URL: https://issues.apache.org/jira/browse/OAK-10833
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.64.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> Excerpt from the erroneous run ({*}failFast{*} option used):
> {noformat}
> Checking /
> Error while traversing /oak:index: Segment
> 53095175-d0e3-4d30-a949-e88ec3175c9c not found
> Checked 1,129 nodes and 3,997 properties
> Checking checkpoint ed24479d-6f98-48af-9679-e7191a2a3765
> Checking /
> Error while traversing /oak:index: Segment
> 53095175-d0e3-4d30-a949-e88ec3175c9c not found
> Checked 1,129 nodes and 3,997 properties
> Checking checkpoint ffeac5ee-85b8-4262-b179-333737015acd
> Checking /
> Checked 4,314,103 nodes and 27,271,618 properties
> Path / is consistent
> Searched through 1 revisions and 3 checkpoints
> Head
> Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46
> from Mar 21, 2024, 11:40:46 AM
> Checkpoints
> - 9b2d7ef8-12ec-4281-8915-34ef5d4413b1
> Latest good revision for path / is none from unknown time
> - ed24479d-6f98-48af-9679-e7191a2a3765
> Latest good revision for path / is none from unknown time
> - ffeac5ee-85b8-4262-b179-333737015acd
> Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46
> Overall
> Latest good revision for paths and checkpoints checked is none from unknown
> time
> TarMK closed {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10833) Consistency check reports success for repository with SNFE in checkpoints
Andrei Dulceanu created OAK-10833:
-
Summary: Consistency check reports success for repository with
SNFE in checkpoints
Key: OAK-10833
URL: https://issues.apache.org/jira/browse/OAK-10833
Project: Jackrabbit Oak
Issue Type: Bug
Components: segment-tar
Affects Versions: 1.64.0
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Excerpt from the erroneous run:
{noformat}
Checking /
Error while traversing /oak:index: Segment 53095175-d0e3-4d30-a949-e88ec3175c9c
not found
Checked 1,129 nodes and 3,997 properties
Checking checkpoint ed24479d-6f98-48af-9679-e7191a2a3765
Checking /
Error while traversing /oak:index: Segment 53095175-d0e3-4d30-a949-e88ec3175c9c
not found
Checked 1,129 nodes and 3,997 properties
Checking checkpoint ffeac5ee-85b8-4262-b179-333737015acd
Checking /
Checked 4,314,103 nodes and 27,271,618 properties
Path / is consistent
Searched through 1 revisions and 3 checkpoints
Head
Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46 from
Mar 21, 2024, 11:40:46 AM
Checkpoints
- 9b2d7ef8-12ec-4281-8915-34ef5d4413b1
Latest good revision for path / is none from unknown time
- ed24479d-6f98-48af-9679-e7191a2a3765
Latest good revision for path / is none from unknown time
- ffeac5ee-85b8-4262-b179-333737015acd
Latest good revision for path / is e6214efd-e302-49a7-a40f-fac8b502267b:46
Overall
Latest good revision for paths and checkpoints checked is none from unknown
time
TarMK closed {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10807) Improve FileStoreBuilder to accept URIs for remote repositories
Andrei Dulceanu created OAK-10807:
-
Summary: Improve FileStoreBuilder to accept URIs for remote
repositories
Key: OAK-10807
URL: https://issues.apache.org/jira/browse/OAK-10807
Project: Jackrabbit Oak
Issue Type: Story
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Currently {{FileStoreBuilder}} accepts only {{File}} path arguments in its
constructor making it impossible to use for {{oak-run}} tooling for remote
repositories. It should accept {{{}URI{}}}s as well, creating by default Azure
persistence backends.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10626) Rework oak-segment-azure OSGi wirings after embedding azure libraries needed for service principals support
[
https://issues.apache.org/jira/browse/OAK-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811333#comment-17811333
]
Andrei Dulceanu commented on OAK-10626:
---
Fixed imports section by not importing the following packages:
{noformat}
!org.reactivestreams.*,
!reactor.core.*,
!reactor.util.*, {noformat}
at
[0a6f99367fd20bf215b4154a76e4a6e422acd2a5|https://github.com/apache/jackrabbit-oak/commit/f2b0cbf937ca550343d3f1d244c879c9936433c1].
> Rework oak-segment-azure OSGi wirings after embedding azure libraries needed
> for service principals support
> ---
>
> Key: OAK-10626
> URL: https://issues.apache.org/jira/browse/OAK-10626
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: osgi, segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> After fixing OAK-10604 I observed that there is a series of warnings which
> appear at each build:
> {noformat}
> [INFO] --- maven-bundle-plugin:5.1.8:bundle (default-bundle) @
> oak-segment-azure ---
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Unused
> Import-Package instructions: [com.nimbusds.jose*, com.nimbusds.oauth2.sdk*,
> com.nimbusds.openid.connect.sdk*, com.nimbusds.secevent.sdk*]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage, has 4, private references
> [com.microsoft.azure.storage.analytics, com.microsoft.azure.storage.file,
> com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage.core, has 2, private references
> [com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage.blob, has 2, private references
> [com.microsoft.azure.keyvault.core, com.microsoft.azure.storage.file]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.azure.identity, has 5, private references
> [com.azure.core.client.traits, com.azure.core.exception, com.azure.core.http,
> com.azure.core.http.policy, com.azure.core.util] {noformat}
> It would be nice to fix these, to remove unnecessary clutter from the build
> log.
> /cc [~miroslav]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10626) Rework oak-segment-azure OSGi wirings after embedding azure libraries needed for service principals support
[
https://issues.apache.org/jira/browse/OAK-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10626:
--
Summary: Rework oak-segment-azure OSGi wirings after embedding azure
libraries needed for service principals support (was: Multiple OSGi
import/export warnings when building oak-segment-azure)
> Rework oak-segment-azure OSGi wirings after embedding azure libraries needed
> for service principals support
> ---
>
> Key: OAK-10626
> URL: https://issues.apache.org/jira/browse/OAK-10626
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: osgi, segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> After fixing OAK-10604 I observed that there is a series of warnings which
> appear at each build:
> {noformat}
> [INFO] --- maven-bundle-plugin:5.1.8:bundle (default-bundle) @
> oak-segment-azure ---
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Unused
> Import-Package instructions: [com.nimbusds.jose*, com.nimbusds.oauth2.sdk*,
> com.nimbusds.openid.connect.sdk*, com.nimbusds.secevent.sdk*]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage, has 4, private references
> [com.microsoft.azure.storage.analytics, com.microsoft.azure.storage.file,
> com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage.core, has 2, private references
> [com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage.blob, has 2, private references
> [com.microsoft.azure.keyvault.core, com.microsoft.azure.storage.file]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.azure.identity, has 5, private references
> [com.azure.core.client.traits, com.azure.core.exception, com.azure.core.http,
> com.azure.core.http.policy, com.azure.core.util] {noformat}
> It would be nice to fix these, to remove unnecessary clutter from the build
> log.
> /cc [~miroslav]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10615) Azure Service Principal Support in oak-run segment-copy, compact, console
[ https://issues.apache.org/jira/browse/OAK-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10615. --- Fix Version/s: 1.62.0 Resolution: Fixed > Azure Service Principal Support in oak-run segment-copy, compact, console > - > > Key: OAK-10615 > URL: https://issues.apache.org/jira/browse/OAK-10615 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.62.0 > > > Azure Service Principal Support in oak-run. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. > Affected commands: segment-copy, compact, console. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10634) Generalise Split segment store persistence
Andrei Dulceanu created OAK-10634:
-
Summary: Generalise Split segment store persistence
Key: OAK-10634
URL: https://issues.apache.org/jira/browse/OAK-10634
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Introduced with OAK-7735,
{quote}Split segment store persistence is a proxy layer that can be used
between the SegmentMK and the actual segment store persistence. It's configured
with two backends: read-only and read-write. It delegates all the read requests
to the read-only backend, but any write request (eg. creating a new segment) is
delegated to the read-write backend.
{quote}
It would be nice to have a generalisation of Split segment store service
allowing the composition of multiple read-only backends and a single read-write
backend.
The main advantage is that we can have multiple segment stores in the cloud
(using the oak-segment-azure), shared amongst many Oak instances, starting
dynamically.
The implementation remembers the state (tar file list, last journal entry) of
the read-only backends during its initialisation, so the read-only backend can
be used by a different instance, as long as it only appends new segments (e.g.
no compaction).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10631) Test with osgi-unit
Andrei Dulceanu created OAK-10631:
-
Summary: Test with osgi-unit
Key: OAK-10631
URL: https://issues.apache.org/jira/browse/OAK-10631
Project: Jackrabbit Oak
Issue Type: Technical task
Reporter: Andrei Dulceanu
Attachments: SplitPersistenceServiceTest-osgi-unit.patch
Try running the test with {{osgi-unit}} [0], OSGi unit tests running on a real
felix. See patch attached.
[0]
https://github.com/apache/sling-whiteboard/tree/org.apache.sling.testing.osgi.unit
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10610) Adding OSGi wiring test for SplitPersistenceService is failing
[
https://issues.apache.org/jira/browse/OAK-10610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-10610:
-
Assignee: Andrei Dulceanu
> Adding OSGi wiring test for SplitPersistenceService is failing
> --
>
> Key: OAK-10610
> URL: https://issues.apache.org/jira/browse/OAK-10610
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: osgi, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
> Attachments: SplitPersistenceServiceTest.patch
>
>
> While running the test in the patch attached, I always get:
> {noformat}
> java.lang.RuntimeException: Unable to invoke method 'deactivate' for class
> org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:325)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeLifecycleMethod(OsgiServiceUtil.java:225)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.shutdown(MockBundleContext.java:449)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.shutdown(MockOsgi.java:330)
> at
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.tearDown(OsgiContextImpl.java:58)
> at
> org.apache.sling.testing.mock.osgi.junit.OsgiContext.access$200(OsgiContext.java:35)
> at
> org.apache.sling.testing.mock.osgi.junit.OsgiContext$1.after(OsgiContext.java:86)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.junit.runners.ParentRunner$<...>.invokeLifecycleMethod(OsgiServiceUtil.java:225)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:218)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.restartService(MockBundleContext.java:202)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.handleRefsUpdateOnUnregister(MockBundleContext.java:259)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.unregisterService(MockBundleContext.java:191)
> at
> org.apache.sling.testing.mock.osgi.MockServiceRegistration.unregister(MockServiceRegistration.java:100)
> at
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard$1.unregister(OsgiWhiteboard.java:87)
> at
> org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService.deactivate(SplitPersistenceService.java:70)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> {noformat}
> The problem is that there is a {{StackOverflowException}} being thrown when
> calling {{deactivate()}}. This might stem from the fact that
> {{SplitPersistenceService}} has a reference to the same type it tries to
> register, but this is only an assumption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10630) Update mock-osgi dependency to see if the issue re-surfaces
Andrei Dulceanu created OAK-10630:
-
Summary: Update mock-osgi dependency to see if the issue
re-surfaces
Key: OAK-10630
URL: https://issues.apache.org/jira/browse/OAK-10630
Project: Jackrabbit Oak
Issue Type: Technical task
Reporter: Andrei Dulceanu
Check to see if updating to \{{3.4.0}} [0] solves the problem.
[0]
https://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.testing.osgi-mock
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10629) Refactor test functionality to check for log messages in oak-segment-*
[ https://issues.apache.org/jira/browse/OAK-10629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10629: -- Epic Link: OAK-10603 > Refactor test functionality to check for log messages in oak-segment-* > -- > > Key: OAK-10629 > URL: https://issues.apache.org/jira/browse/OAK-10629 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-azure, segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > Currently we're using this in > [DefaultSegmentWriterTest|https://github.com/apache/jackrabbit-oak/blob/6a04b335eeaf9b7cb7f689605463c3ac0c38b269/oak-segment-tar/src/test/java/org/apache/jackrabbit/oak/segment/DefaultSegmentWriterTest.java#L319], > but in OAK-10615 the same code was copy-pasted in > [ToolUtilsTest|https://github.com/apache/jackrabbit-oak/blob/8cab6c5b3ae232baf3920c9039afa950dbf65b55/oak-segment-azure/src/test/java/org/apache/jackrabbit/oak/segment/azure/tool/ToolUtilsTest.java#L168-L182]. > It would be nice to abstract this in its own utility class to avoid code > duplication. Other usages in Oak [0]. > [0] > https://github.com/search?q=repo%3Aapache%2Fjackrabbit-oak%20ILoggingEvent=code -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10629) Refactor test functionality to check for log messages in oak-segment-*
Andrei Dulceanu created OAK-10629: - Summary: Refactor test functionality to check for log messages in oak-segment-* Key: OAK-10629 URL: https://issues.apache.org/jira/browse/OAK-10629 Project: Jackrabbit Oak Issue Type: Task Components: segment-azure, segment-tar Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu Currently we're using this in [DefaultSegmentWriterTest|https://github.com/apache/jackrabbit-oak/blob/6a04b335eeaf9b7cb7f689605463c3ac0c38b269/oak-segment-tar/src/test/java/org/apache/jackrabbit/oak/segment/DefaultSegmentWriterTest.java#L319], but in OAK-10615 the same code was copy-pasted in [ToolUtilsTest|https://github.com/apache/jackrabbit-oak/blob/8cab6c5b3ae232baf3920c9039afa950dbf65b55/oak-segment-azure/src/test/java/org/apache/jackrabbit/oak/segment/azure/tool/ToolUtilsTest.java#L168-L182]. It would be nice to abstract this in its own utility class to avoid code duplication. Other usages in Oak [0]. [0] https://github.com/search?q=repo%3Aapache%2Fjackrabbit-oak%20ILoggingEvent=code -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10628) Azure Service Principal Support in oak-run
[ https://issues.apache.org/jira/browse/OAK-10628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10628: -- Description: Azure Service Principal Support in oak-run. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. Affected commands: datastore, explore. was: Azure Service Principal Support in oak-run. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. Affected commands: datastore. > Azure Service Principal Support in oak-run > -- > > Key: OAK-10628 > URL: https://issues.apache.org/jira/browse/OAK-10628 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > Azure Service Principal Support in oak-run. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. > Affected commands: datastore, explore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10628) Azure Service Principal Support in oak-run
[ https://issues.apache.org/jira/browse/OAK-10628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10628: -- Description: Azure Service Principal Support in oak-run. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. Affected commands: datastore. > Azure Service Principal Support in oak-run > -- > > Key: OAK-10628 > URL: https://issues.apache.org/jira/browse/OAK-10628 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Priority: Major > > Azure Service Principal Support in oak-run. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. > Affected commands: datastore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10628) Azure Service Principal Support in oak-run
[ https://issues.apache.org/jira/browse/OAK-10628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-10628: - Assignee: Andrei Dulceanu > Azure Service Principal Support in oak-run > -- > > Key: OAK-10628 > URL: https://issues.apache.org/jira/browse/OAK-10628 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > Azure Service Principal Support in oak-run. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. > Affected commands: datastore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10628) Azure Service Principal Support in oak-run
[ https://issues.apache.org/jira/browse/OAK-10628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10628: -- Epic Link: OAK-10603 > Azure Service Principal Support in oak-run > -- > > Key: OAK-10628 > URL: https://issues.apache.org/jira/browse/OAK-10628 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > Azure Service Principal Support in oak-run. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. > Affected commands: datastore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10628) Azure Service Principal Support in oak-run
Andrei Dulceanu created OAK-10628: - Summary: Azure Service Principal Support in oak-run Key: OAK-10628 URL: https://issues.apache.org/jira/browse/OAK-10628 Project: Jackrabbit Oak Issue Type: Story Components: oak-run, segment-azure Reporter: Andrei Dulceanu -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10615) Azure Service Principal Support in oak-run segment-copy, compact, console
[ https://issues.apache.org/jira/browse/OAK-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10615: -- Summary: Azure Service Principal Support in oak-run segment-copy, compact, console (was: Azure Service Principal Support in oak-run) > Azure Service Principal Support in oak-run segment-copy, compact, console > - > > Key: OAK-10615 > URL: https://issues.apache.org/jira/browse/OAK-10615 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > Azure Service Principal Support in oak-run. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. > Affected commands: segment-copy, compact, console. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10626) Multiple OSGi import/export warnings when building oak-segment-azure
[
https://issues.apache.org/jira/browse/OAK-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10626:
--
Description:
After fixing OAK-10604 I observed that there is a series of warnings which
appear at each build:
{noformat}
[INFO] --- maven-bundle-plugin:5.1.8:bundle (default-bundle) @
oak-segment-azure ---
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Unused Import-Package instructions: [com.nimbusds.jose*,
com.nimbusds.oauth2.sdk*, com.nimbusds.openid.connect.sdk*,
com.nimbusds.secevent.sdk*]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage, has 4, private references
[com.microsoft.azure.storage.analytics, com.microsoft.azure.storage.file,
com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage.core, has 2, private references
[com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage.blob, has 2, private references
[com.microsoft.azure.keyvault.core, com.microsoft.azure.storage.file]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.azure.identity, has 5, private references
[com.azure.core.client.traits, com.azure.core.exception, com.azure.core.http,
com.azure.core.http.policy, com.azure.core.util] {noformat}
It would be nice to fix these, to remove unnecessary clutter from the build log.
/cc [~miroslav]
was:
After fixing OAK-10604 I observed that there is a series of warnings which
appear at each build:
{noformat}
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Unused Import-Package instructions: [com.nimbusds.jose*,
com.nimbusds.oauth2.sdk*, com.nimbusds.openid.connect.sdk*,
com.nimbusds.secevent.sdk*]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage, has 4, private references
[com.microsoft.azure.storage.analytics, com.microsoft.azure.storage.file,
com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage.core, has 2, private references
[com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage.blob, has 2, private references
[com.microsoft.azure.keyvault.core, com.microsoft.azure.storage.file]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.azure.identity, has 5, private references
[com.azure.core.client.traits, com.azure.core.exception, com.azure.core.http,
com.azure.core.http.policy, com.azure.core.util] {noformat}
It would be nice to fix these, to remove unnecessary clutter from the build log.
/cc [~miroslav]
> Multiple OSGi import/export warnings when building oak-segment-azure
>
>
> Key: OAK-10626
> URL: https://issues.apache.org/jira/browse/OAK-10626
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: osgi, segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> After fixing OAK-10604 I observed that there is a series of warnings which
> appear at each build:
> {noformat}
> [INFO] --- maven-bundle-plugin:5.1.8:bundle (default-bundle) @
> oak-segment-azure ---
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Unused
> Import-Package instructions: [com.nimbusds.jose*, com.nimbusds.oauth2.sdk*,
> com.nimbusds.openid.connect.sdk*, com.nimbusds.secevent.sdk*]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage, has 4, private references
> [com.microsoft.azure.storage.analytics, com.microsoft.azure.storage.file,
> com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage.core, has 2, private references
> [com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
> com.microsoft.azure.storage.blob, has 2, private references
> [com.microsoft.azure.keyvault.core, com.microsoft.azure.storage.file]
> [WARNING] Manifest
> org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT : Export
>
[jira] [Created] (OAK-10626) Multiple OSGi import/export warnings when building oak-segment-azure
Andrei Dulceanu created OAK-10626:
-
Summary: Multiple OSGi import/export warnings when building
oak-segment-azure
Key: OAK-10626
URL: https://issues.apache.org/jira/browse/OAK-10626
Project: Jackrabbit Oak
Issue Type: Task
Components: osgi, segment-azure
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
After fixing OAK-10604 I observed that there is a series of warnings which
appear at each build:
{noformat}
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Unused Import-Package instructions: [com.nimbusds.jose*,
com.nimbusds.oauth2.sdk*, com.nimbusds.openid.connect.sdk*,
com.nimbusds.secevent.sdk*]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage, has 4, private references
[com.microsoft.azure.storage.analytics, com.microsoft.azure.storage.file,
com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage.core, has 2, private references
[com.microsoft.azure.storage.queue, com.microsoft.azure.storage.table]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.microsoft.azure.storage.blob, has 2, private references
[com.microsoft.azure.keyvault.core, com.microsoft.azure.storage.file]
[WARNING] Manifest org.apache.jackrabbit:oak-segment-azure:bundle:1.61-SNAPSHOT
: Export com.azure.identity, has 5, private references
[com.azure.core.client.traits, com.azure.core.exception, com.azure.core.http,
com.azure.core.http.policy, com.azure.core.util] {noformat}
It would be nice to fix these, to remove unnecessary clutter from the build log.
/cc [~miroslav]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10614) AzureJournalFileConcurrencyIT takes too long to execute
[
https://issues.apache.org/jira/browse/OAK-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810393#comment-17810393
]
Andrei Dulceanu commented on OAK-10614:
---
A different thing now, this time a failure:
{noformat}
[INFO] Running org.apache.jackrabbit.oak.segment.azure.AzureJournalFileTest
[ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.687 s
<<< FAILURE! - in org.apache.jackrabbit.oak.segment.azure.AzureJournalFileTest
[ERROR]
testEnsureBatchWriteLinesIsFasterThanNaiveImplementation(org.apache.jackrabbit.oak.segment.azure.AzureJournalFileTest)
Time elapsed: 1.26 s <<< FAILURE!
java.lang.AssertionError: batchWriteLines() should be significantly faster
(>10x) than the naive implementation, but took 114ms while naive implementation
took 1123ms
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.assertTrue(Assert.java:42)
at
org.apache.jackrabbit.oak.segment.azure.AzureJournalFileTest.testEnsureBatchWriteLinesIsFasterThanNaiveImplementation(AzureJournalFileTest.java:155)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.apache.jackrabbit.oak.blob.cloud.azure.blobstorage.AzuriteDockerRule$1.evaluate(AzuriteDockerRule.java:84)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
{noformat}
> AzureJournalFileConcurrencyIT takes too long to execute
> ---
>
> Key: OAK-10614
> URL: https://issues.apache.org/jira/browse/OAK-10614
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-azure
>Affects Versions: 1.60.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> Running
> [AzureJournalFileConcurrencyIT|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-azure/src/test/java/org/apache/jackrabbit/oak/segment/azure/AzureJournalFileConcurrencyIT.java]
> currently takes over 5 minutes on my machine to execute. We should refactor
> this test to either use Azurite or tweak its configuration to take less time.
> /cc [~miroslav]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10615) Azure Service Principal Support in oak-run
[ https://issues.apache.org/jira/browse/OAK-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10615: -- Description: Azure Service Principal Support in oak-run. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. Affected commands: segment-copy, compact, console. was: Azure Service Principal Support in oak-run. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. Affected commands: segment-copy, compact, check, console. > Azure Service Principal Support in oak-run > -- > > Key: OAK-10615 > URL: https://issues.apache.org/jira/browse/OAK-10615 > Project: Jackrabbit Oak > Issue Type: Story > Components: oak-run, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > Azure Service Principal Support in oak-run. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. > Affected commands: segment-copy, compact, console. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10604) Azure Service Principal Support in oak-segment-azure
[ https://issues.apache.org/jira/browse/OAK-10604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10604. --- Fix Version/s: 1.62.0 Resolution: Fixed > Azure Service Principal Support in oak-segment-azure > > > Key: OAK-10604 > URL: https://issues.apache.org/jira/browse/OAK-10604 > Project: Jackrabbit Oak > Issue Type: Story > Components: segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.62.0 > > > Azure Service Principal Support in oak-segment-azure. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10618) ArrayIndexOutOfBoundsException in TikaExtractionOsgiIT
Andrei Dulceanu created OAK-10618:
-
Summary: ArrayIndexOutOfBoundsException in TikaExtractionOsgiIT
Key: OAK-10618
URL: https://issues.apache.org/jira/browse/OAK-10618
Project: Jackrabbit Oak
Issue Type: Bug
Components: indexing, osgi
Affects Versions: 1.60.0
Reporter: Andrei Dulceanu
Every time I run tests with the integration profile in {{{}oak-it-osgi{}}},
*TikaExtractionOsgiIT* outputs the following stack trace which clutters the
tests output:
{noformat}
java.lang.ArrayIndexOutOfBoundsException: Index 19 out of bounds for length 19
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:579)
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:497)
at aQute.bnd.osgi.Clazz.parseClassFileWithCollector(Clazz.java:486)
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:476)
at aQute.bnd.osgi.Analyzer.analyzeJar(Analyzer.java:2196)
at aQute.bnd.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:2102)
at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:139)
at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:618)
at org.ops4j.pax.swissbox.bnd.BndUtils.createBundle(BndUtils.java:161)
at
org.ops4j.pax.url.wrap.internal.Connection.getInputStream(Connection.java:83)
at java.base/java.net.URL.openStream(URL.java:1165)
at
org.ops4j.pax.exam.forked.provision.StreamUtils.streamCopy(StreamUtils.java:103)
at
org.ops4j.pax.exam.forked.provision.PlatformImpl.download(PlatformImpl.java:133)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.downloadBundle(ForkedTestContainer.java:356)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.installAndStartBundles(ForkedTestContainer.java:284)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:165)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:457)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
java.lang.ArrayIndexOutOfBoundsException: Index 19 out of bounds for length 19
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:579)
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:497)
at aQute.bnd.osgi.Clazz.parseClassFileWithCollector(Clazz.java:486)
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:476)
at aQute.bnd.osgi.Analyzer.analyzeJar(Analyzer.java:2196)
at aQute.bnd.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:2102)
at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:139)
at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:618)
at org.ops4j.pax.swissbox.bnd.BndUtils.createBundle(BndUtils.java:161)
at
org.ops4j.pax.url.wrap.internal.Connection.getInputStream(Connection.java:83)
at java.base/java.net.URL.openStream(URL.java:1165)
at
org.ops4j.pax.exam.forked.provision.StreamUtils.streamCopy(StreamUtils.java:103)
at
org.ops4j.pax.exam.forked.provision.PlatformImpl.download(PlatformImpl.java:133)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.downloadBundle(ForkedTestContainer.java:356)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.installAndStartBundles(ForkedTestContainer.java:284)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:165)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:457)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
[jira] [Created] (OAK-10615) Azure Service Principal Support in oak-run
Andrei Dulceanu created OAK-10615: - Summary: Azure Service Principal Support in oak-run Key: OAK-10615 URL: https://issues.apache.org/jira/browse/OAK-10615 Project: Jackrabbit Oak Issue Type: Story Components: oak-run, segment-azure Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu Azure Service Principal Support in oak-run. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. Affected commands: segment-copy, compact, check, console. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10614) AzureJournalFileConcurrencyIT takes too long to execute
Andrei Dulceanu created OAK-10614: - Summary: AzureJournalFileConcurrencyIT takes too long to execute Key: OAK-10614 URL: https://issues.apache.org/jira/browse/OAK-10614 Project: Jackrabbit Oak Issue Type: Task Components: segment-azure Affects Versions: 1.60.0 Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu Running [AzureJournalFileConcurrencyIT|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-azure/src/test/java/org/apache/jackrabbit/oak/segment/azure/AzureJournalFileConcurrencyIT.java] currently takes over 5 minutes on my machine to execute. We should refactor this test to either use Azurite or tweak its configuration to take less time. /cc [~miroslav] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10610) Adding OSGi wiring test for SplitPersistenceService is failing
[
https://issues.apache.org/jira/browse/OAK-10610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808124#comment-17808124
]
Andrei Dulceanu commented on OAK-10610:
---
[~jsedding], since you originally added {{SplitPersistenceService}}, would you
be able to look into it, please?
> Adding OSGi wiring test for SplitPersistenceService is failing
> --
>
> Key: OAK-10610
> URL: https://issues.apache.org/jira/browse/OAK-10610
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: osgi, segment-tar
>Reporter: Andrei Dulceanu
>Priority: Minor
> Attachments: SplitPersistenceServiceTest.patch
>
>
> While running the test in the patch attached, I always get:
> {noformat}
> java.lang.RuntimeException: Unable to invoke method 'deactivate' for class
> org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:325)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeLifecycleMethod(OsgiServiceUtil.java:225)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.shutdown(MockBundleContext.java:449)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.shutdown(MockOsgi.java:330)
> at
> org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.tearDown(OsgiContextImpl.java:58)
> at
> org.apache.sling.testing.mock.osgi.junit.OsgiContext.access$200(OsgiContext.java:35)
> at
> org.apache.sling.testing.mock.osgi.junit.OsgiContext$1.after(OsgiContext.java:86)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.junit.runners.ParentRunner$<...>.invokeLifecycleMethod(OsgiServiceUtil.java:225)
> at
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
> at
> org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:218)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.restartService(MockBundleContext.java:202)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.handleRefsUpdateOnUnregister(MockBundleContext.java:259)
> at
> org.apache.sling.testing.mock.osgi.MockBundleContext.unregisterService(MockBundleContext.java:191)
> at
> org.apache.sling.testing.mock.osgi.MockServiceRegistration.unregister(MockServiceRegistration.java:100)
> at
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard$1.unregister(OsgiWhiteboard.java:87)
> at
> org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService.deactivate(SplitPersistenceService.java:70)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> {noformat}
> The problem is that there is a {{StackOverflowException}} being thrown when
> calling {{deactivate()}}. This might stem from the fact that
> {{SplitPersistenceService}} has a reference to the same type it tries to
> register, but this is only an assumption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10610) Adding OSGi wiring test for SplitPersistenceService is failing
Andrei Dulceanu created OAK-10610:
-
Summary: Adding OSGi wiring test for SplitPersistenceService is
failing
Key: OAK-10610
URL: https://issues.apache.org/jira/browse/OAK-10610
Project: Jackrabbit Oak
Issue Type: Task
Components: osgi, segment-tar
Reporter: Andrei Dulceanu
Attachments: SplitPersistenceServiceTest.patch
While running the test in the patch attached, I always get:
{noformat}
java.lang.RuntimeException: Unable to invoke method 'deactivate' for class
org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeMethod(OsgiServiceUtil.java:325)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.invokeLifecycleMethod(OsgiServiceUtil.java:225)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
at
org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
at
org.apache.sling.testing.mock.osgi.MockBundleContext.shutdown(MockBundleContext.java:449)
at
org.apache.sling.testing.mock.osgi.MockOsgi.shutdown(MockOsgi.java:330)
at
org.apache.sling.testing.mock.osgi.context.OsgiContextImpl.tearDown(OsgiContextImpl.java:58)
at
org.apache.sling.testing.mock.osgi.junit.OsgiContext.access$200(OsgiContext.java:35)
at
org.apache.sling.testing.mock.osgi.junit.OsgiContext$1.after(OsgiContext.java:86)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:59)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at
org.junit.runners.ParentRunner$<...>.invokeLifecycleMethod(OsgiServiceUtil.java:225)
at
org.apache.sling.testing.mock.osgi.OsgiServiceUtil.activateDeactivate(OsgiServiceUtil.java:89)
at
org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:231)
at
org.apache.sling.testing.mock.osgi.MockOsgi.deactivate(MockOsgi.java:218)
at
org.apache.sling.testing.mock.osgi.MockBundleContext.restartService(MockBundleContext.java:202)
at
org.apache.sling.testing.mock.osgi.MockBundleContext.handleRefsUpdateOnUnregister(MockBundleContext.java:259)
at
org.apache.sling.testing.mock.osgi.MockBundleContext.unregisterService(MockBundleContext.java:191)
at
org.apache.sling.testing.mock.osgi.MockServiceRegistration.unregister(MockServiceRegistration.java:100)
at
org.apache.jackrabbit.oak.osgi.OsgiWhiteboard$1.unregister(OsgiWhiteboard.java:87)
at
org.apache.jackrabbit.oak.segment.osgi.SplitPersistenceService.deactivate(SplitPersistenceService.java:70)
at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
{noformat}
The problem is that there is a {{StackOverflowException}} being thrown when
calling {{deactivate()}}. This might stem from the fact that
{{SplitPersistenceService}} has a reference to the same type it tries to
register, but this is only an assumption.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10217) Build Jackrabbit/jackrabbit-oak-trunk #919 failed
[ https://issues.apache.org/jira/browse/OAK-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10217. --- Fix Version/s: 1.62.0 Resolution: Fixed Resolving this as the test hasn't failed lately. > Build Jackrabbit/jackrabbit-oak-trunk #919 failed > - > > Key: OAK-10217 > URL: https://issues.apache.org/jira/browse/OAK-10217 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.62.0 > > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #919 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #919|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (OAK-10217) Build Jackrabbit/jackrabbit-oak-trunk #919 failed
[ https://issues.apache.org/jira/browse/OAK-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu closed OAK-10217. - > Build Jackrabbit/jackrabbit-oak-trunk #919 failed > - > > Key: OAK-10217 > URL: https://issues.apache.org/jira/browse/OAK-10217 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.62.0 > > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #919 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #919|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10217) Build Jackrabbit/jackrabbit-oak-trunk #919 failed
[ https://issues.apache.org/jira/browse/OAK-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-10217: - Assignee: Andrei Dulceanu > Build Jackrabbit/jackrabbit-oak-trunk #919 failed > - > > Key: OAK-10217 > URL: https://issues.apache.org/jira/browse/OAK-10217 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Assignee: Andrei Dulceanu >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #919 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #919|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/919/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10603) Azure Service Principal Support in Azure Segment Store and Blob Store
[ https://issues.apache.org/jira/browse/OAK-10603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10603: -- Description: bq. An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources. Think of it as a 'user identity' (login and password or certificate) with a specific role, and tightly controlled permissions to access your resources. It only needs to be able to do specific things, unlike a general user identity. It improves security if you only grant it the minimum permissions level needed to perform its management tasks.([Source|https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?toc=%2Fazure%2Fazure-resource-manager%2Ftoc.json=azure-cli-latest]) This epic covers adding Azure Service Principal support in oak-segment-azure and blob-cloud-azure modules, allowing Azure authentication by providing: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. was: bq. An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources. Think of it as a 'user identity' (login and password or certificate) with a specific role, and tightly controlled permissions to access your resources. It only needs to be able to do specific things, unlike a general user identity. It improves security if you only grant it the minimum permissions level needed to perform its management tasks.([Source|https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?toc=%2Fazure%2Fazure-resource-manager%2Ftoc.json=azure-cli-latest]) This epic covers adding Azure Service Principal support in oak-segment-azure and blob-cloud-azure modules, allowing Azure authentication by providing: * appId - Id of the Service Principal object / App registered with the Active Directory. * password - Application password. * tenantId - Azure Active Directory Id. > Azure Service Principal Support in Azure Segment Store and Blob Store > - > > Key: OAK-10603 > URL: https://issues.apache.org/jira/browse/OAK-10603 > Project: Jackrabbit Oak > Issue Type: Epic > Components: blob-cloud-azure, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > bq. An Azure service principal is a security identity used by user-created > apps, services, and automation tools to access specific Azure resources. > Think of it as a 'user identity' (login and password or certificate) with a > specific role, and tightly controlled permissions to access your resources. > It only needs to be able to do specific things, unlike a general user > identity. It improves security if you only grant it the minimum permissions > level needed to perform its management > tasks.([Source|https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?toc=%2Fazure%2Fazure-resource-manager%2Ftoc.json=azure-cli-latest]) > This epic covers adding Azure Service Principal support in oak-segment-azure > and blob-cloud-azure modules, allowing Azure authentication by providing: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10604) Azure Service Principal Support in oak-segment-azure
[ https://issues.apache.org/jira/browse/OAK-10604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10604: -- Description: Azure Service Principal Support in oak-segment-azure. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. was: Azure Service Principal Support in oak-segment-azure. Goal is to allow Azure authentication via: * appId - Id of the Service Principal object / App registered with the Active Directory. * password - Application password. * tenantId - Azure Active Directory Id. > Azure Service Principal Support in oak-segment-azure > > > Key: OAK-10604 > URL: https://issues.apache.org/jira/browse/OAK-10604 > Project: Jackrabbit Oak > Issue Type: Story > Components: segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > Azure Service Principal Support in oak-segment-azure. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10603) Azure Service Principal Support in Azure Segment Store and Blob Store
[ https://issues.apache.org/jira/browse/OAK-10603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-10603: - Assignee: Andrei Dulceanu > Azure Service Principal Support in Azure Segment Store and Blob Store > - > > Key: OAK-10603 > URL: https://issues.apache.org/jira/browse/OAK-10603 > Project: Jackrabbit Oak > Issue Type: Epic > Components: blob-cloud-azure, segment-azure >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > > bq. An Azure service principal is a security identity used by user-created > apps, services, and automation tools to access specific Azure resources. > Think of it as a 'user identity' (login and password or certificate) with a > specific role, and tightly controlled permissions to access your resources. > It only needs to be able to do specific things, unlike a general user > identity. It improves security if you only grant it the minimum permissions > level needed to perform its management > tasks.([Source|https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?toc=%2Fazure%2Fazure-resource-manager%2Ftoc.json=azure-cli-latest]) > This epic covers adding Azure Service Principal support in oak-segment-azure > and blob-cloud-azure modules, allowing Azure authentication by providing: > * appId - Id of the Service Principal object / App registered with the Active > Directory. > * password - Application password. > * tenantId - Azure Active Directory Id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10604) Azure Service Principal Support in oak-segment-azure
Andrei Dulceanu created OAK-10604: - Summary: Azure Service Principal Support in oak-segment-azure Key: OAK-10604 URL: https://issues.apache.org/jira/browse/OAK-10604 Project: Jackrabbit Oak Issue Type: Story Components: segment-azure Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu Azure Service Principal Support in oak-segment-azure. Goal is to allow Azure authentication via: * appId - Id of the Service Principal object / App registered with the Active Directory. * password - Application password. * tenantId - Azure Active Directory Id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10603) Azure Service Principal Support in Azure Segment Store and Blob Store
Andrei Dulceanu created OAK-10603: - Summary: Azure Service Principal Support in Azure Segment Store and Blob Store Key: OAK-10603 URL: https://issues.apache.org/jira/browse/OAK-10603 Project: Jackrabbit Oak Issue Type: Epic Components: blob-cloud-azure, segment-azure Reporter: Andrei Dulceanu bq. An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources. Think of it as a 'user identity' (login and password or certificate) with a specific role, and tightly controlled permissions to access your resources. It only needs to be able to do specific things, unlike a general user identity. It improves security if you only grant it the minimum permissions level needed to perform its management tasks.([Source|https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?toc=%2Fazure%2Fazure-resource-manager%2Ftoc.json=azure-cli-latest]) This epic covers adding Azure Service Principal support in oak-segment-azure and blob-cloud-azure modules, allowing Azure authentication by providing: * appId - Id of the Service Principal object / App registered with the Active Directory. * password - Application password. * tenantId - Azure Active Directory Id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.104.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10591. --- Resolution: Fixed > Bump netty dependency from 4.1.96.Final to 4.1.104.Final > > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.62.0 > > > *File Matche(s):* > /netty-common-4.1.96.Final.jar > *Vulnerabilitie(s)* > This artifact embeds Netty Project 4.1.96.Final which contains the following > vulnerabilitie(s): > *BDSA-2023-2732/CVE-2023-44487* in version 4.1.96.Final (CVSS 7.5 High): The > HTTP/2 protocol contains a flaw related to the stream multiplexing feature > that can allow for excessive resource consumption on servers operating > implementations of the HTTP/2 protocol. The HTTP/2 protocol allows clients to > signal to a server to cancel a previously opened stream by sending an > `RST_STREAM` frame. Attackers can abuse this stream canceling ability by > opening a large number of streams at once immediately followed by > `RST_STREAM` frames. In most HTTP/2 implementations this bypasses concurrent > open stream limits and causes servers to spend processing time first handling > request frames and then performing stream tear downs. For the server, these > operations can pile up whereas the attacker client paid minuscule bandwidth > and processing costs. > [Amazon](https://aws.amazon.com/security/security-bulletins/AWS-2023-011/), > [Cloudflare](https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/) > and > [Google](https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/) > have reported that this vulnerability has been exploited in the wild from > August to October 2023. This vulnerability is listed as exploitable by the > Cybersecurity & Infrastructure Security Agency in their [Known Exploited > Vulnerabilities > Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.104.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799716#comment-17799716 ] Andrei Dulceanu commented on OAK-10591: --- Fixed in trunk at [6e5b58060bca300e3a0e9a43e8be1c7a52b95840|https://github.com/apache/jackrabbit-oak/commit/6e5b58060bca300e3a0e9a43e8be1c7a52b95840]. > Bump netty dependency from 4.1.96.Final to 4.1.104.Final > > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.62.0 > > > *File Matche(s):* > /netty-common-4.1.96.Final.jar > *Vulnerabilitie(s)* > This artifact embeds Netty Project 4.1.96.Final which contains the following > vulnerabilitie(s): > *BDSA-2023-2732/CVE-2023-44487* in version 4.1.96.Final (CVSS 7.5 High): The > HTTP/2 protocol contains a flaw related to the stream multiplexing feature > that can allow for excessive resource consumption on servers operating > implementations of the HTTP/2 protocol. The HTTP/2 protocol allows clients to > signal to a server to cancel a previously opened stream by sending an > `RST_STREAM` frame. Attackers can abuse this stream canceling ability by > opening a large number of streams at once immediately followed by > `RST_STREAM` frames. In most HTTP/2 implementations this bypasses concurrent > open stream limits and causes servers to spend processing time first handling > request frames and then performing stream tear downs. For the server, these > operations can pile up whereas the attacker client paid minuscule bandwidth > and processing costs. > [Amazon](https://aws.amazon.com/security/security-bulletins/AWS-2023-011/), > [Cloudflare](https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/) > and > [Google](https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/) > have reported that this vulnerability has been exploited in the wild from > August to October 2023. This vulnerability is listed as exploitable by the > Cybersecurity & Infrastructure Security Agency in their [Known Exploited > Vulnerabilities > Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.104.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799717#comment-17799717 ] Andrei Dulceanu commented on OAK-10591: --- Fixed in 1.22 at [b348485e4c938a685136f56849c06235f1209aaa|https://github.com/apache/jackrabbit-oak/commit/b348485e4c938a685136f56849c06235f1209aaa]. > Bump netty dependency from 4.1.96.Final to 4.1.104.Final > > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.62.0 > > > *File Matche(s):* > /netty-common-4.1.96.Final.jar > *Vulnerabilitie(s)* > This artifact embeds Netty Project 4.1.96.Final which contains the following > vulnerabilitie(s): > *BDSA-2023-2732/CVE-2023-44487* in version 4.1.96.Final (CVSS 7.5 High): The > HTTP/2 protocol contains a flaw related to the stream multiplexing feature > that can allow for excessive resource consumption on servers operating > implementations of the HTTP/2 protocol. The HTTP/2 protocol allows clients to > signal to a server to cancel a previously opened stream by sending an > `RST_STREAM` frame. Attackers can abuse this stream canceling ability by > opening a large number of streams at once immediately followed by > `RST_STREAM` frames. In most HTTP/2 implementations this bypasses concurrent > open stream limits and causes servers to spend processing time first handling > request frames and then performing stream tear downs. For the server, these > operations can pile up whereas the attacker client paid minuscule bandwidth > and processing costs. > [Amazon](https://aws.amazon.com/security/security-bulletins/AWS-2023-011/), > [Cloudflare](https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/) > and > [Google](https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/) > have reported that this vulnerability has been exploited in the wild from > August to October 2023. This vulnerability is listed as exploitable by the > Cybersecurity & Infrastructure Security Agency in their [Known Exploited > Vulnerabilities > Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.104.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10591: -- Description: *File Matche(s):* /netty-common-4.1.96.Final.jar *Vulnerabilitie(s)* This artifact embeds Netty Project 4.1.96.Final which contains the following vulnerabilitie(s): *BDSA-2023-2732/CVE-2023-44487* in version 4.1.96.Final (CVSS 7.5 High): The HTTP/2 protocol contains a flaw related to the stream multiplexing feature that can allow for excessive resource consumption on servers operating implementations of the HTTP/2 protocol. The HTTP/2 protocol allows clients to signal to a server to cancel a previously opened stream by sending an `RST_STREAM` frame. Attackers can abuse this stream canceling ability by opening a large number of streams at once immediately followed by `RST_STREAM` frames. In most HTTP/2 implementations this bypasses concurrent open stream limits and causes servers to spend processing time first handling request frames and then performing stream tear downs. For the server, these operations can pile up whereas the attacker client paid minuscule bandwidth and processing costs. [Amazon](https://aws.amazon.com/security/security-bulletins/AWS-2023-011/), [Cloudflare](https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/) and [Google](https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/) have reported that this vulnerability has been exploited in the wild from August to October 2023. This vulnerability is listed as exploitable by the Cybersecurity & Infrastructure Security Agency in their [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). was: io.netty : netty-codec : 4.1.52.Final sonatype-2021-0789 *Summary*: sonatype-2021-0789 Explanation The netty-codec package contains a Buffer Overflow vulnerability. The finishEncode function in the Lz4FrameEncoder.class class incorrectly estimates the buffer size when writing a footer for the last header. An attacker could abuse this behavior by sending a payload to the flawed application that will overwrite contiguous memory chunks in the heap, resulting in a Denial of Service (DoS) condition or other unintended behavior. Detection The application is vulnerable by using this component. Recommendation We recommend upgrading to a version of this component that is not vulnerable to this specific issue. Note: If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or a potential mitigating control. Root Cause netty-codec-4.1.52.Final.jar <= io/netty/handler/codec/compression/Lz4FrameEncoder.class:[4.1.0.Beta2 , 4.1.66.Final) Advisories Project: [https://github.com/netty/netty/pull/11429] > Bump netty dependency from 4.1.96.Final to 4.1.104.Final > > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.62.0 > > > *File Matche(s):* > /netty-common-4.1.96.Final.jar > *Vulnerabilitie(s)* > This artifact embeds Netty Project 4.1.96.Final which contains the following > vulnerabilitie(s): > *BDSA-2023-2732/CVE-2023-44487* in version 4.1.96.Final (CVSS 7.5 High): The > HTTP/2 protocol contains a flaw related to the stream multiplexing feature > that can allow for excessive resource consumption on servers operating > implementations of the HTTP/2 protocol. The HTTP/2 protocol allows clients to > signal to a server to cancel a previously opened stream by sending an > `RST_STREAM` frame. Attackers can abuse this stream canceling ability by > opening a large number of streams at once immediately followed by > `RST_STREAM` frames. In most HTTP/2 implementations this bypasses concurrent > open stream limits and causes servers to spend processing time first handling > request frames and then performing stream tear downs. For the server, these > operations can pile up whereas the attacker client paid minuscule bandwidth > and processing costs. > [Amazon](https://aws.amazon.com/security/security-bulletins/AWS-2023-011/), > [Cloudflare](https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/) > and >
[jira] [Updated] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.104.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10591: -- Summary: Bump netty dependency from 4.1.96.Final to 4.1.104.Final (was: Bump netty dependency from 4.1.96.Final to 4.1.66.Final) > Bump netty dependency from 4.1.96.Final to 4.1.104.Final > > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.62.0 > > > io.netty : netty-codec : 4.1.52.Final sonatype-2021-0789 > *Summary*: > sonatype-2021-0789 > Explanation > The netty-codec package contains a Buffer Overflow vulnerability. The > finishEncode function in the Lz4FrameEncoder.class class incorrectly > estimates the buffer size when writing a footer for the last header. An > attacker could abuse this behavior by sending a payload to the flawed > application that will overwrite contiguous memory chunks in the heap, > resulting in a Denial of Service (DoS) condition or other unintended behavior. > Detection > The application is vulnerable by using this component. > Recommendation > We recommend upgrading to a version of this component that is not vulnerable > to this specific issue. > Note: If this component is included as a bundled/transitive dependency of > another component, there may not be an upgrade path. In this instance, we > recommend contacting the maintainers who included the vulnerable package. > Alternatively, we recommend investigating alternative components or a > potential mitigating control. > Root Cause > netty-codec-4.1.52.Final.jar <= > io/netty/handler/codec/compression/Lz4FrameEncoder.class:[4.1.0.Beta2 , > 4.1.66.Final) > Advisories > Project: > [https://github.com/netty/netty/pull/11429] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.66.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10591: -- Reporter: Andrei Dulceanu (was: Arun Kumar Ram) > Bump netty dependency from 4.1.96.Final to 4.1.66.Final > --- > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.42.0, 1.22.9 > > > io.netty : netty-codec : 4.1.52.Final sonatype-2021-0789 > *Summary*: > sonatype-2021-0789 > Explanation > The netty-codec package contains a Buffer Overflow vulnerability. The > finishEncode function in the Lz4FrameEncoder.class class incorrectly > estimates the buffer size when writing a footer for the last header. An > attacker could abuse this behavior by sending a payload to the flawed > application that will overwrite contiguous memory chunks in the heap, > resulting in a Denial of Service (DoS) condition or other unintended behavior. > Detection > The application is vulnerable by using this component. > Recommendation > We recommend upgrading to a version of this component that is not vulnerable > to this specific issue. > Note: If this component is included as a bundled/transitive dependency of > another component, there may not be an upgrade path. In this instance, we > recommend contacting the maintainers who included the vulnerable package. > Alternatively, we recommend investigating alternative components or a > potential mitigating control. > Root Cause > netty-codec-4.1.52.Final.jar <= > io/netty/handler/codec/compression/Lz4FrameEncoder.class:[4.1.0.Beta2 , > 4.1.66.Final) > Advisories > Project: > [https://github.com/netty/netty/pull/11429] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.66.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10591: -- Fix Version/s: 1.62.0 (was: 1.42.0) (was: 1.22.9) > Bump netty dependency from 4.1.96.Final to 4.1.66.Final > --- > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.62.0 > > > io.netty : netty-codec : 4.1.52.Final sonatype-2021-0789 > *Summary*: > sonatype-2021-0789 > Explanation > The netty-codec package contains a Buffer Overflow vulnerability. The > finishEncode function in the Lz4FrameEncoder.class class incorrectly > estimates the buffer size when writing a footer for the last header. An > attacker could abuse this behavior by sending a payload to the flawed > application that will overwrite contiguous memory chunks in the heap, > resulting in a Denial of Service (DoS) condition or other unintended behavior. > Detection > The application is vulnerable by using this component. > Recommendation > We recommend upgrading to a version of this component that is not vulnerable > to this specific issue. > Note: If this component is included as a bundled/transitive dependency of > another component, there may not be an upgrade path. In this instance, we > recommend contacting the maintainers who included the vulnerable package. > Alternatively, we recommend investigating alternative components or a > potential mitigating control. > Root Cause > netty-codec-4.1.52.Final.jar <= > io/netty/handler/codec/compression/Lz4FrameEncoder.class:[4.1.0.Beta2 , > 4.1.66.Final) > Advisories > Project: > [https://github.com/netty/netty/pull/11429] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10591) Bump netty dependency from 4.1.96.Final to 4.1.66.Final
[ https://issues.apache.org/jira/browse/OAK-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10591: -- Summary: Bump netty dependency from 4.1.96.Final to 4.1.66.Final (was: CLONE - Bump netty dependency from 4.1.52.Final to 4.1.66.Final) > Bump netty dependency from 4.1.96.Final to 4.1.66.Final > --- > > Key: OAK-10591 > URL: https://issues.apache.org/jira/browse/OAK-10591 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Arun Kumar Ram >Assignee: Andrei Dulceanu >Priority: Major > Labels: vulnerability > Fix For: 1.42.0, 1.22.9 > > > io.netty : netty-codec : 4.1.52.Final sonatype-2021-0789 > *Summary*: > sonatype-2021-0789 > Explanation > The netty-codec package contains a Buffer Overflow vulnerability. The > finishEncode function in the Lz4FrameEncoder.class class incorrectly > estimates the buffer size when writing a footer for the last header. An > attacker could abuse this behavior by sending a payload to the flawed > application that will overwrite contiguous memory chunks in the heap, > resulting in a Denial of Service (DoS) condition or other unintended behavior. > Detection > The application is vulnerable by using this component. > Recommendation > We recommend upgrading to a version of this component that is not vulnerable > to this specific issue. > Note: If this component is included as a bundled/transitive dependency of > another component, there may not be an upgrade path. In this instance, we > recommend contacting the maintainers who included the vulnerable package. > Alternatively, we recommend investigating alternative components or a > potential mitigating control. > Root Cause > netty-codec-4.1.52.Final.jar <= > io/netty/handler/codec/compression/Lz4FrameEncoder.class:[4.1.0.Beta2 , > 4.1.66.Final) > Advisories > Project: > [https://github.com/netty/netty/pull/11429] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10591) CLONE - Bump netty dependency from 4.1.52.Final to 4.1.66.Final
Andrei Dulceanu created OAK-10591: - Summary: CLONE - Bump netty dependency from 4.1.52.Final to 4.1.66.Final Key: OAK-10591 URL: https://issues.apache.org/jira/browse/OAK-10591 Project: Jackrabbit Oak Issue Type: Task Components: segment-tar Reporter: Arun Kumar Ram Assignee: Andrei Dulceanu Fix For: 1.42.0, 1.22.9 io.netty : netty-codec : 4.1.52.Final sonatype-2021-0789 *Summary*: sonatype-2021-0789 Explanation The netty-codec package contains a Buffer Overflow vulnerability. The finishEncode function in the Lz4FrameEncoder.class class incorrectly estimates the buffer size when writing a footer for the last header. An attacker could abuse this behavior by sending a payload to the flawed application that will overwrite contiguous memory chunks in the heap, resulting in a Denial of Service (DoS) condition or other unintended behavior. Detection The application is vulnerable by using this component. Recommendation We recommend upgrading to a version of this component that is not vulnerable to this specific issue. Note: If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or a potential mitigating control. Root Cause netty-codec-4.1.52.Final.jar <= io/netty/handler/codec/compression/Lz4FrameEncoder.class:[4.1.0.Beta2 , 4.1.66.Final) Advisories Project: [https://github.com/netty/netty/pull/11429] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10311) Optimize SegmentBlob#equals for segment blobs that originate from the same blob store
[ https://issues.apache.org/jira/browse/OAK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10311. --- Fix Version/s: 1.60.0 Resolution: Fixed > Optimize SegmentBlob#equals for segment blobs that originate from the same > blob store > - > > Key: OAK-10311 > URL: https://issues.apache.org/jira/browse/OAK-10311 > Project: Jackrabbit Oak > Issue Type: Story > Components: segment-tar >Affects Versions: 1.52.0 >Reporter: Axel Hanikel >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.60.0 > > > [SegmentBlob#equals|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.52.0/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java] > can be optimized for blobs originating from the same external blob store: In > that case, SegmentBlob#getBlobId() can be used to determine if the blobs are > equal or not. That change should avoid falling back to a byte-by-byte > comparison if the two blobs have the same size, which can be very expensive > for larger blobs. > The optimization should be placed behind a code/feature toggle or system > property and disabled by default. The reason is that the contract of > [Blob#getContentIdentity|https://github.com/apache/jackrabbit-oak/blob/cc0521e1cf8dc10ad7a8d41a9f2d3fd2905e5c9b/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java#L80-L82] > does not mention the special case where Blobs reside in the same blob store. > As part of this story, integration and benchmark tests should be created to > demonstrate gains in performance and correct behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9949) Enable offline tail compaction
[ https://issues.apache.org/jira/browse/OAK-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-9949. -- Fix Version/s: 1.60.0 Resolution: Fixed > Enable offline tail compaction > -- > > Key: OAK-9949 > URL: https://issues.apache.org/jira/browse/OAK-9949 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws, segment-azure, segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Minor > Fix For: 1.60.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10472) Move ApproximateCounter from oak-core to a place where it can be used by oak-segment-tar
[ https://issues.apache.org/jira/browse/OAK-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-10472: - Assignee: Andrei Dulceanu > Move ApproximateCounter from oak-core to a place where it can be used by > oak-segment-tar > > > Key: OAK-10472 > URL: https://issues.apache.org/jira/browse/OAK-10472 > Project: Jackrabbit Oak > Issue Type: Wish > Components: core >Reporter: Julian Reschke >Assignee: Andrei Dulceanu >Priority: Major > > Maybe oak-store-spi? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-9922) Parallel Compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-9922. -- Fix Version/s: 1.58.0 Resolution: Fixed > Parallel Compaction > --- > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > Fix For: 1.58.0 > > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-9922) Parallel Compaction
[ https://issues.apache.org/jira/browse/OAK-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-9922: Assignee: Andrei Dulceanu > Parallel Compaction > --- > > Key: OAK-9922 > URL: https://issues.apache.org/jira/browse/OAK-9922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Major > > Add ability to parallelize compaction over subtrees with multiple threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10311) Optimize SegmentBlob#equals for segment blobs that originate from the same blob store
[ https://issues.apache.org/jira/browse/OAK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-10311: - Assignee: Andrei Dulceanu > Optimize SegmentBlob#equals for segment blobs that originate from the same > blob store > - > > Key: OAK-10311 > URL: https://issues.apache.org/jira/browse/OAK-10311 > Project: Jackrabbit Oak > Issue Type: Story > Components: segment-tar >Affects Versions: 1.52.0 >Reporter: Axel Hanikel >Assignee: Andrei Dulceanu >Priority: Major > > [SegmentBlob#equals|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.52.0/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java] > can be optimized for blobs originating from the same external blob store: In > that case, SegmentBlob#getBlobId() can be used to determine if the blobs are > equal or not. That change should avoid falling back to a byte-by-byte > comparison if the two blobs have the same size, which can be very expensive > for larger blobs. > The optimization should be placed behind a code/feature toggle or system > property and disabled by default. The reason is that the contract of > [Blob#getContentIdentity|https://github.com/apache/jackrabbit-oak/blob/cc0521e1cf8dc10ad7a8d41a9f2d3fd2905e5c9b/oak-api/src/main/java/org/apache/jackrabbit/oak/api/Blob.java#L80-L82] > does not mention the special case where Blobs reside in the same blob store. > As part of this story, integration and benchmark tests should be created to > demonstrate gains in performance and correct behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-9949) Enable offline tail compaction
[ https://issues.apache.org/jira/browse/OAK-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-9949: Assignee: Andrei Dulceanu > Enable offline tail compaction > -- > > Key: OAK-9949 > URL: https://issues.apache.org/jira/browse/OAK-9949 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-aws, segment-azure, segment-tar >Reporter: Lucas Weitzendorf >Assignee: Andrei Dulceanu >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10293) AzureTarRevisionsTest fails occasionally
[
https://issues.apache.org/jira/browse/OAK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767177#comment-17767177
]
Andrei Dulceanu commented on OAK-10293:
---
[~reschke], doing a bisect I found that these failures started to happen after
OAK-10022 was merged in trunk. Recently OAK-10272 reverted the changes in
OAK-10022. I tested extensively locally and I couldn't reproduce the failures
on current trunk. I propose to close this issue for now.
Regarding the last failure reported by you, this is really strange, as the only
append blob that we have in the azure implementation is the journal, but that
one is not exercised in those tests. Please include the full stacktrace next
time, if it happens again.
> AzureTarRevisionsTest fails occasionally
>
>
> Key: OAK-10293
> URL: https://issues.apache.org/jira/browse/OAK-10293
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Marcel Reutegger
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> {noformat}
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.395
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest
> [ERROR]
> setHeadFromFunction(org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest)
> Time elapsed: 0.043 s <<< ERROR!
> org.apache.jackrabbit.oak.segment.file.InvalidFileStoreVersionException:
> Using oak-segment-tar, but oak-segment should be used
> at
> org.apache.jackrabbit.oak.segment.file.ManifestChecker.openManifest(ManifestChecker.java:65)
> at
> org.apache.jackrabbit.oak.segment.file.ManifestChecker.checkAndUpdateManifest(ManifestChecker.java:51)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:153)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:445)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisionsTest.setup(TarRevisionsTest.java:74)
> at
> org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest.setup(AzureTarRevisionsTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10293) AzureTarRevisionsTest fails occasionally
[
https://issues.apache.org/jira/browse/OAK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10293.
---
Fix Version/s: 1.58.0
Resolution: Fixed
> AzureTarRevisionsTest fails occasionally
>
>
> Key: OAK-10293
> URL: https://issues.apache.org/jira/browse/OAK-10293
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Marcel Reutegger
>Assignee: Andrei Dulceanu
>Priority: Minor
> Fix For: 1.58.0
>
>
> {noformat}
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.395
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest
> [ERROR]
> setHeadFromFunction(org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest)
> Time elapsed: 0.043 s <<< ERROR!
> org.apache.jackrabbit.oak.segment.file.InvalidFileStoreVersionException:
> Using oak-segment-tar, but oak-segment should be used
> at
> org.apache.jackrabbit.oak.segment.file.ManifestChecker.openManifest(ManifestChecker.java:65)
> at
> org.apache.jackrabbit.oak.segment.file.ManifestChecker.checkAndUpdateManifest(ManifestChecker.java:51)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:153)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:445)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisionsTest.setup(TarRevisionsTest.java:74)
> at
> org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest.setup(AzureTarRevisionsTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10376) AzureSegmentStoreServiceTest: strange behavior when Docker not running
[
https://issues.apache.org/jira/browse/OAK-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-10376:
-
Assignee: Andrei Dulceanu
> AzureSegmentStoreServiceTest: strange behavior when Docker not running
> --
>
> Key: OAK-10376
> URL: https://issues.apache.org/jira/browse/OAK-10376
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> I see a mildly weird behavior with this test when Docker is not running:
> {noformat}
> [INFO] Running
> org.apache.jackrabbit.oak.segment.azure.AzureSegmentStoreServiceTest
> [WARNING] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed:
> 1.845 s - in
> org.apache.jackrabbit.oak.segment.azure.AzureSegmentStoreServiceTest
> {noformat}
> however, when docker *is* running, it reports *6* tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10360) unreliable test AzureTarFileTest.testWriteAndReadBinaryReferences
[
https://issues.apache.org/jira/browse/OAK-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10360.
---
Fix Version/s: 1.58.0
Resolution: Fixed
> unreliable test AzureTarFileTest.testWriteAndReadBinaryReferences
> --
>
> Key: OAK-10360
> URL: https://issues.apache.org/jira/browse/OAK-10360
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.58.0
>
>
> {noformat}
> [INFO] [ERROR]
> AzureTarFileTest>TarFileTest.testWriteAndReadBinaryReferences:174
> expected:<{GCGeneration{generation=1,fullGeneration=0,isCompacted=false}={--0001--0001=[r1],
> --0001--=[r0],
> --0001--0003=[r3],
> --0001--0002=[r2]},
> GCGeneration{generation=2,fullGeneration=0,isCompacted=false}={--0002--0002=[r6],
> --0002--=[r4],
> --0002--0001=[r5]},
> GCGeneration{generation=3,fullGeneration=0,isCompacted=false}={--0003--0001=[r8],
> --0003--=[r7]}}> but was:<{}>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10343) AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter unreliable
[
https://issues.apache.org/jira/browse/OAK-10343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10343.
---
Fix Version/s: 1.58.0
Resolution: Fixed
> AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter unreliable
> --
>
> Key: OAK-10343
> URL: https://issues.apache.org/jira/browse/OAK-10343
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.58.0
>
>
> This happens frequently for me (Windows):
> {noformat}
> [ERROR] Tests run: 20, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 3.560 s <<< FAILURE! -- in org.apache.jackrabbit.oak.segment.azure.
> AzureTarFilesTest
> [ERROR]
> org.apache.jackrabbit.oak.segment.azure.AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter
> -- Time elapsed: 0.192 s <<<
> FAILURE!
> java.lang.AssertionError: expected:<[]> but was:<[ok]>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:120)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFilesTest.testCollectBlobReferencesWithGenerationFilter(TarFilesTest.java:290)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:76)
> at
> org.apache.jackrabbit.oak.blob.cloud.azure.blobstorage.AzuriteDockerRule$1.evaluate(AzuriteDockerRule.java:112)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10359) Unreliable test: TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep
[
https://issues.apache.org/jira/browse/OAK-10359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10359.
---
Fix Version/s: 1.58.0
Resolution: Fixed
> Unreliable test: TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep
>
>
> Key: OAK-10359
> URL: https://issues.apache.org/jira/browse/OAK-10359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.58.0
>
>
> {noformat}
> [INFO] [ERROR] Tests run: 7, Failures: 1, Errors: 0, Skipped: 1, Time
> elapsed: 1.582 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.azure.AzureTarFileTest
> [INFO] [ERROR]
> binaryReferencesIndexShouldBeTrimmedDownOnSweep(org.apache.jackrabbit.oak.segment.azure.AzureTarFileTest)
> Time elapsed: 0.375 s <<< FAILURE!
> [INFO] java.lang.AssertionError:
> expected:<{GCGeneration{generation=1,fullGeneration=0,isCompacted=false}={--0001--0002=[b]},
>
> GCGeneration{generation=2,fullGeneration=0,isCompacted=false}={--0002--0001=[c]}}>
> but was:<{}>
> [INFO] at org.junit.Assert.fail(Assert.java:89)
> [INFO] at org.junit.Assert.failNotEquals(Assert.java:835)
> [INFO] at org.junit.Assert.assertEquals(Assert.java:120)
> [INFO] at org.junit.Assert.assertEquals(Assert.java:146)
> [INFO] at
> org.apache.jackrabbit.oak.segment.file.tar.TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep(TarFileTest.java:217)
> [INFO] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [INFO] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [INFO] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [INFO] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [INFO] at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> [INFO] at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10359) Unreliable test: TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep
[
https://issues.apache.org/jira/browse/OAK-10359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765610#comment-17765610
]
Andrei Dulceanu commented on OAK-10359:
---
[~reschke], doing a bisect I found that these failures started to happen after
OAK-10022 was merged in trunk. Recently OAK-10272 reverted the changes in
OAK-10022. I tested extensively locally and I couldn't reproduce the failures
on current trunk. I propose to close this issue for now. Do you agree?
> Unreliable test: TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep
>
>
> Key: OAK-10359
> URL: https://issues.apache.org/jira/browse/OAK-10359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] [ERROR] Tests run: 7, Failures: 1, Errors: 0, Skipped: 1, Time
> elapsed: 1.582 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.azure.AzureTarFileTest
> [INFO] [ERROR]
> binaryReferencesIndexShouldBeTrimmedDownOnSweep(org.apache.jackrabbit.oak.segment.azure.AzureTarFileTest)
> Time elapsed: 0.375 s <<< FAILURE!
> [INFO] java.lang.AssertionError:
> expected:<{GCGeneration{generation=1,fullGeneration=0,isCompacted=false}={--0001--0002=[b]},
>
> GCGeneration{generation=2,fullGeneration=0,isCompacted=false}={--0002--0001=[c]}}>
> but was:<{}>
> [INFO] at org.junit.Assert.fail(Assert.java:89)
> [INFO] at org.junit.Assert.failNotEquals(Assert.java:835)
> [INFO] at org.junit.Assert.assertEquals(Assert.java:120)
> [INFO] at org.junit.Assert.assertEquals(Assert.java:146)
> [INFO] at
> org.apache.jackrabbit.oak.segment.file.tar.TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep(TarFileTest.java:217)
> [INFO] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [INFO] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [INFO] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [INFO] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [INFO] at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> [INFO] at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10359) Unreliable test: TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep
[
https://issues.apache.org/jira/browse/OAK-10359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-10359:
-
Assignee: Andrei Dulceanu
> Unreliable test: TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep
>
>
> Key: OAK-10359
> URL: https://issues.apache.org/jira/browse/OAK-10359
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
>
> {noformat}
> [INFO] [ERROR] Tests run: 7, Failures: 1, Errors: 0, Skipped: 1, Time
> elapsed: 1.582 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.azure.AzureTarFileTest
> [INFO] [ERROR]
> binaryReferencesIndexShouldBeTrimmedDownOnSweep(org.apache.jackrabbit.oak.segment.azure.AzureTarFileTest)
> Time elapsed: 0.375 s <<< FAILURE!
> [INFO] java.lang.AssertionError:
> expected:<{GCGeneration{generation=1,fullGeneration=0,isCompacted=false}={--0001--0002=[b]},
>
> GCGeneration{generation=2,fullGeneration=0,isCompacted=false}={--0002--0001=[c]}}>
> but was:<{}>
> [INFO] at org.junit.Assert.fail(Assert.java:89)
> [INFO] at org.junit.Assert.failNotEquals(Assert.java:835)
> [INFO] at org.junit.Assert.assertEquals(Assert.java:120)
> [INFO] at org.junit.Assert.assertEquals(Assert.java:146)
> [INFO] at
> org.apache.jackrabbit.oak.segment.file.tar.TarFileTest.binaryReferencesIndexShouldBeTrimmedDownOnSweep(TarFileTest.java:217)
> [INFO] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [INFO] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [INFO] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [INFO] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [INFO] at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> [INFO] at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10360) unreliable test AzureTarFileTest.testWriteAndReadBinaryReferences
[
https://issues.apache.org/jira/browse/OAK-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-10360:
-
Assignee: Andrei Dulceanu
> unreliable test AzureTarFileTest.testWriteAndReadBinaryReferences
> --
>
> Key: OAK-10360
> URL: https://issues.apache.org/jira/browse/OAK-10360
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
>
> {noformat}
> [INFO] [ERROR]
> AzureTarFileTest>TarFileTest.testWriteAndReadBinaryReferences:174
> expected:<{GCGeneration{generation=1,fullGeneration=0,isCompacted=false}={--0001--0001=[r1],
> --0001--=[r0],
> --0001--0003=[r3],
> --0001--0002=[r2]},
> GCGeneration{generation=2,fullGeneration=0,isCompacted=false}={--0002--0002=[r6],
> --0002--=[r4],
> --0002--0001=[r5]},
> GCGeneration{generation=3,fullGeneration=0,isCompacted=false}={--0003--0001=[r8],
> --0003--=[r7]}}> but was:<{}>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10360) unreliable test AzureTarFileTest.testWriteAndReadBinaryReferences
[
https://issues.apache.org/jira/browse/OAK-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765609#comment-17765609
]
Andrei Dulceanu commented on OAK-10360:
---
[~reschke], doing a bisect I found that these failures started to happen after
OAK-10022 was merged in trunk. Recently OAK-10272 reverted the changes in
OAK-10022. I tested extensively locally and I couldn't reproduce the failures
on current trunk. I propose to close this issue for now. Do you agree?
> unreliable test AzureTarFileTest.testWriteAndReadBinaryReferences
> --
>
> Key: OAK-10360
> URL: https://issues.apache.org/jira/browse/OAK-10360
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] [ERROR]
> AzureTarFileTest>TarFileTest.testWriteAndReadBinaryReferences:174
> expected:<{GCGeneration{generation=1,fullGeneration=0,isCompacted=false}={--0001--0001=[r1],
> --0001--=[r0],
> --0001--0003=[r3],
> --0001--0002=[r2]},
> GCGeneration{generation=2,fullGeneration=0,isCompacted=false}={--0002--0002=[r6],
> --0002--=[r4],
> --0002--0001=[r5]},
> GCGeneration{generation=3,fullGeneration=0,isCompacted=false}={--0003--0001=[r8],
> --0003--=[r7]}}> but was:<{}>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10343) AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter unreliable
[
https://issues.apache.org/jira/browse/OAK-10343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765606#comment-17765606
]
Andrei Dulceanu commented on OAK-10343:
---
[~reschke], doing a bisect I found that these failures started to happen after
OAK-10022 was merged in trunk. Recently OAK-10272 reverted the changes in
OAK-10022. I tested extensively locally and I couldn't reproduce the failures
on current trunk. I propose to close this issue for now. Do you agree?
> AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter unreliable
> --
>
> Key: OAK-10343
> URL: https://issues.apache.org/jira/browse/OAK-10343
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
>
> This happens frequently for me (Windows):
> {noformat}
> [ERROR] Tests run: 20, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 3.560 s <<< FAILURE! -- in org.apache.jackrabbit.oak.segment.azure.
> AzureTarFilesTest
> [ERROR]
> org.apache.jackrabbit.oak.segment.azure.AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter
> -- Time elapsed: 0.192 s <<<
> FAILURE!
> java.lang.AssertionError: expected:<[]> but was:<[ok]>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:120)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFilesTest.testCollectBlobReferencesWithGenerationFilter(TarFilesTest.java:290)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:76)
> at
> org.apache.jackrabbit.oak.blob.cloud.azure.blobstorage.AzuriteDockerRule$1.evaluate(AzuriteDockerRule.java:112)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> {noformat}
--
This message
[jira] [Assigned] (OAK-10343) AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter unreliable
[
https://issues.apache.org/jira/browse/OAK-10343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-10343:
-
Assignee: Andrei Dulceanu
> AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter unreliable
> --
>
> Key: OAK-10343
> URL: https://issues.apache.org/jira/browse/OAK-10343
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Julian Reschke
>Assignee: Andrei Dulceanu
>Priority: Major
>
> This happens frequently for me (Windows):
> {noformat}
> [ERROR] Tests run: 20, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 3.560 s <<< FAILURE! -- in org.apache.jackrabbit.oak.segment.azure.
> AzureTarFilesTest
> [ERROR]
> org.apache.jackrabbit.oak.segment.azure.AzureTarFilesTest.testCollectBlobReferencesWithGenerationFilter
> -- Time elapsed: 0.192 s <<<
> FAILURE!
> java.lang.AssertionError: expected:<[]> but was:<[ok]>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:120)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFilesTest.testCollectBlobReferencesWithGenerationFilter(TarFilesTest.java:290)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> com.arakelian.docker.junit.DockerRule$StatementWithDockerRule.evaluate(DockerRule.java:76)
> at
> org.apache.jackrabbit.oak.blob.cloud.azure.blobstorage.AzuriteDockerRule$1.evaluate(AzuriteDockerRule.java:112)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10293) AzureTarRevisionsTest fails occasionally
[
https://issues.apache.org/jira/browse/OAK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-10293:
-
Assignee: Andrei Dulceanu
> AzureTarRevisionsTest fails occasionally
>
>
> Key: OAK-10293
> URL: https://issues.apache.org/jira/browse/OAK-10293
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Marcel Reutegger
>Assignee: Andrei Dulceanu
>Priority: Minor
>
> {noformat}
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.395
> s <<< FAILURE! - in
> org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest
> [ERROR]
> setHeadFromFunction(org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest)
> Time elapsed: 0.043 s <<< ERROR!
> org.apache.jackrabbit.oak.segment.file.InvalidFileStoreVersionException:
> Using oak-segment-tar, but oak-segment should be used
> at
> org.apache.jackrabbit.oak.segment.file.ManifestChecker.openManifest(ManifestChecker.java:65)
> at
> org.apache.jackrabbit.oak.segment.file.ManifestChecker.checkAndUpdateManifest(ManifestChecker.java:51)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:153)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:445)
> at
> org.apache.jackrabbit.oak.segment.file.TarRevisionsTest.setup(TarRevisionsTest.java:74)
> at
> org.apache.jackrabbit.oak.segment.azure.journal.AzureTarRevisionsTest.setup(AzureTarRevisionsTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10289) segment-tar: switch away from com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap
[ https://issues.apache.org/jira/browse/OAK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730977#comment-17730977 ] Andrei Dulceanu commented on OAK-10289: --- [~reschke], sure looking into it. > segment-tar: switch away from > com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap > > > Key: OAK-10289 > URL: https://issues.apache.org/jira/browse/OAK-10289 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Julian Reschke >Priority: Minor > > ...which isn't maintained anymore. > I *guess* there's an equivalent way using Guava. > See also > https://stackoverflow.com/questions/15299554/what-does-it-mean-that-concurrentlinkedhashmap-has-been-integrated-into-guava/15305232#15305232 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10289) segment-tar: switch away from com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap
[ https://issues.apache.org/jira/browse/OAK-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu reassigned OAK-10289: - Assignee: Andrei Dulceanu > segment-tar: switch away from > com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap > > > Key: OAK-10289 > URL: https://issues.apache.org/jira/browse/OAK-10289 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Reporter: Julian Reschke >Assignee: Andrei Dulceanu >Priority: Minor > > ...which isn't maintained anymore. > I *guess* there's an equivalent way using Guava. > See also > https://stackoverflow.com/questions/15299554/what-does-it-mean-that-concurrentlinkedhashmap-has-been-integrated-into-guava/15305232#15305232 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10263) Inconsistent state in TarWriter when close() fails to write to Azure
[
https://issues.apache.org/jira/browse/OAK-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10263.
---
Fix Version/s: 1.54.0
Resolution: Fixed
> Inconsistent state in TarWriter when close() fails to write to Azure
> -
>
> Key: OAK-10263
> URL: https://issues.apache.org/jira/browse/OAK-10263
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure, segment-tar
>Reporter: Carlo Jelmini
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.54.0
>
>
> When using AzurePersistence as backend, a TarWriter can end up in an
> inconsistent state.
> The root cause of this inconsistent state is the following sequence:
> * TarFiles writes a new segment
> * The current tar archive is now too large and a new tar archive needs to be
> created
> * However, first the TarWriter associated to the current archive need to be
> closed
> * In the TarWriter#close() method, first the {{closed}} flag is set, then it
> proceeds to close the archive by writing the binary references file and the
> graph file.
> * The write to Azure storage fails because of a timeout: "The client could
> not finish the operation within specified maximum execution timeout"
> * The TarWriter is now closed (because the {{closed}} flag is already set),
> but because the exception is basically ignored by FileStore#tryFlush(), the
> TarWriter is kept in use and fails all read and write operations from that
> point forward. The read operation failures cause calling code to interpret
> the exception as a SNFE.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (OAK-10263) Inconsistent state in TarWriter when close() fails to write to Azure
[
https://issues.apache.org/jira/browse/OAK-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu reassigned OAK-10263:
-
Assignee: Andrei Dulceanu
> Inconsistent state in TarWriter when close() fails to write to Azure
> -
>
> Key: OAK-10263
> URL: https://issues.apache.org/jira/browse/OAK-10263
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure, segment-tar
>Reporter: Carlo Jelmini
>Assignee: Andrei Dulceanu
>Priority: Major
>
> When using AzurePersistence as backend, a TarWriter can end up in an
> inconsistent state.
> The root cause of this inconsistent state is the following sequence:
> * TarFiles writes a new segment
> * The current tar archive is now too large and a new tar archive needs to be
> created
> * However, first the TarWriter associated to the current archive need to be
> closed
> * In the TarWriter#close() method, first the {{closed}} flag is set, then it
> proceeds to close the archive by writing the binary references file and the
> graph file.
> * The write to Azure storage fails because of a timeout: "The client could
> not finish the operation within specified maximum execution timeout"
> * The TarWriter is now closed (because the {{closed}} flag is already set),
> but because the exception is basically ignored by FileStore#tryFlush(), the
> TarWriter is kept in use and fails all read and write operations from that
> point forward. The read operation failures cause calling code to interpret
> the exception as a SNFE.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10191) Reusing Azure blob container hangs when primary location is not available
[
https://issues.apache.org/jira/browse/OAK-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10191.
---
Fix Version/s: 1.52.0
Resolution: Fixed
> Reusing Azure blob container hangs when primary location is not available
> -
>
> Key: OAK-10191
> URL: https://issues.apache.org/jira/browse/OAK-10191
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob-cloud-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.52.0
>
>
> When access to the secondary Azure blobstore service endpoint in Oak blob
> store is enabled (see OAK-10049), re-using the Azure segment container hangs
> if the primary location is not available.
> This happens because the call {{container.createIfNotExists()}} always
> overrides the request options set and goes to primary location only, since
> that is the only one allowing write access (in case the container needs to be
> created).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10190) Reusing Azure segment container hangs when primary location is not available
[
https://issues.apache.org/jira/browse/OAK-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10190.
---
Resolution: Fixed
> Reusing Azure segment container hangs when primary location is not available
>
>
> Key: OAK-10190
> URL: https://issues.apache.org/jira/browse/OAK-10190
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.52.0
>
>
> When access to the secondary Azure blobstore service endpoint in Oak segment
> node store is enabled (see OAK-10050), re-using the Azure segment container
> hangs if the primary location is not available.
> This happens because the call {{container.createIfNotExists()}} always
> overrides the request options set and goes to primary location only, since
> that is the only one allowing write access (in case the container needs to be
> created).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10190) Reusing Azure segment container hangs when primary location is not available
[
https://issues.apache.org/jira/browse/OAK-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10190:
--
Fix Version/s: 1.52.0
> Reusing Azure segment container hangs when primary location is not available
>
>
> Key: OAK-10190
> URL: https://issues.apache.org/jira/browse/OAK-10190
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.52.0
>
>
> When access to the secondary Azure blobstore service endpoint in Oak segment
> node store is enabled (see OAK-10050), re-using the Azure segment container
> hangs if the primary location is not available.
> This happens because the call {{container.createIfNotExists()}} always
> overrides the request options set and goes to primary location only, since
> that is the only one allowing write access (in case the container needs to be
> created).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10191) Reusing Azure blob container hangs when primary location is not available
Andrei Dulceanu created OAK-10191:
-
Summary: Reusing Azure blob container hangs when primary location
is not available
Key: OAK-10191
URL: https://issues.apache.org/jira/browse/OAK-10191
Project: Jackrabbit Oak
Issue Type: Bug
Components: blob-cloud-azure
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
When access to the secondary Azure blobstore service endpoint in Oak blob store
is enabled (see OAK-10049), re-using the Azure segment container hangs if the
primary location is not available.
This happens because the call {{container.createIfNotExists()}} always
overrides the request options set and goes to primary location only, since that
is the only one allowing write access (in case the container needs to be
created).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10190) Reusing Azure segment container hangs when primary location is not available
[
https://issues.apache.org/jira/browse/OAK-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10190:
--
Issue Type: Bug (was: Task)
> Reusing Azure segment container hangs when primary location is not available
>
>
> Key: OAK-10190
> URL: https://issues.apache.org/jira/browse/OAK-10190
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>
> When access to the secondary Azure blobstore service endpoint in Oak segment
> node store is enabled (see OAK-10050), re-using the Azure segment container
> hangs if the primary location is not available.
> This happens because the call {{container.createIfNotExists()}} always
> overrides the request options set and goes to primary location only, since
> that is the only one allowing write access (in case the container needs to be
> created).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10190) Reusing Azure segment container hangs when primary location is not available
Andrei Dulceanu created OAK-10190:
-
Summary: Reusing Azure segment container hangs when primary
location is not available
Key: OAK-10190
URL: https://issues.apache.org/jira/browse/OAK-10190
Project: Jackrabbit Oak
Issue Type: Task
Components: segment-azure
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
When access to the secondary Azure blobstore service endpoint in Oak segment
node store is enabled (see OAK-10050), re-using the Azure segment container
hangs if the primary location is not available.
This happens because the call {{container.createIfNotExists()}} always
overrides the request options set and goes to primary location only, since that
is the only one allowing write access (in case the container needs to be
created).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10050) Enable access to the secondary Azure blobstore service endpoint in Oak segment node store
[
https://issues.apache.org/jira/browse/OAK-10050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10050.
---
Fix Version/s: 1.52.0
Resolution: Fixed
> Enable access to the secondary Azure blobstore service endpoint in Oak
> segment node store
> -
>
> Key: OAK-10050
> URL: https://issues.apache.org/jira/browse/OAK-10050
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.52.0
>
>
> Create a property for the azure segment store to enable fallback to the
> secondary location
> ({{{}requestOptions.setLocationMode(LocationMode.PRIMARY_THEN_SECONDARY);{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10101) Improve exception message when retrieving String properties
[
https://issues.apache.org/jira/browse/OAK-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu resolved OAK-10101.
---
Resolution: Fixed
Fixed in trunk at
[aa492521af6bbe6f3bc3a75e6044d568f42ed5ed|https://github.com/apache/jackrabbit-oak/commit/aa492521af6bbe6f3bc3a75e6044d568f42ed5ed].
> Improve exception message when retrieving String properties
> ---
>
> Key: OAK-10101
> URL: https://issues.apache.org/jira/browse/OAK-10101
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
>Affects Versions: 1.48.0
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.50.0
>
>
> If we have a property of type {{BINARIES}} and we try to read it, using the
> Oak API, as an array of {{{}STRING{}}}, then the exception message of the
> correctly raised {{IllegalStateException}} is:
> {noformat}
> java.lang.IllegalStateException: String is too long: 2325884045577463478"
> (where the number is basically random) {noformat}
> In order to give a hint to the caller about what might go wrong, we should
> improve the exception message:
> {noformat}
> throw new IllegalStateException("String is too long: " + length + "; possibly
> trying to read a BLOB using getString; can not convert BLOB to String");
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-10101) Improve exception message when retrieving String properties
Andrei Dulceanu created OAK-10101:
-
Summary: Improve exception message when retrieving String
properties
Key: OAK-10101
URL: https://issues.apache.org/jira/browse/OAK-10101
Project: Jackrabbit Oak
Issue Type: Task
Components: segment-tar
Affects Versions: 1.48.0
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Fix For: 1.50.0
If we have a property of type {{BINARIES}} and we try to read it, using the Oak
API, as an array of {{{}STRING{}}}, then the exception message of the correctly
raised {{IllegalStateException}} is:
{noformat}
java.lang.IllegalStateException: String is too long: 2325884045577463478"
(where the number is basically random) {noformat}
In order to give a hint to the caller about what might go wrong, we should
improve the exception message:
{noformat}
throw new IllegalStateException("String is too long: " + length + "; possibly
trying to read a BLOB using getString; can not convert BLOB to String");
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10076) Bump netty dependency from 4.1.68.Final to 4.1.86.Final
[ https://issues.apache.org/jira/browse/OAK-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10076: -- Fix Version/s: 1.22.15 > Bump netty dependency from 4.1.68.Final to 4.1.86.Final > --- > > Key: OAK-10076 > URL: https://issues.apache.org/jira/browse/OAK-10076 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Affects Versions: 1.46.0, 1.22.14 >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: candidate_oak_1_22, cold-standby, vulnerability > Fix For: 1.48.0, 1.22.15 > > > *Vulnerabilities* > CVE-2022-41881 > A StackOverflowError can be raised when parsing a malformed crafted message > due to an > infinite recursion. > [https://github.com/netty/netty/security/advisories/GHSA-fx2c-96vj-985v|https://github.com/netty/netty/security/advisories/GHSA-grg4-wf29-r9vv] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10076) Bump netty dependency from 4.1.68.Final to 4.1.86.Final
[ https://issues.apache.org/jira/browse/OAK-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu resolved OAK-10076. --- Resolution: Fixed > Bump netty dependency from 4.1.68.Final to 4.1.86.Final > --- > > Key: OAK-10076 > URL: https://issues.apache.org/jira/browse/OAK-10076 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Affects Versions: 1.46.0, 1.22.14 >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: candidate_oak_1_22, cold-standby, vulnerability > Fix For: 1.50.0 > > > *Vulnerabilities* > CVE-2022-41881 > A StackOverflowError can be raised when parsing a malformed crafted message > due to an > infinite recursion. > [https://github.com/netty/netty/security/advisories/GHSA-fx2c-96vj-985v|https://github.com/netty/netty/security/advisories/GHSA-grg4-wf29-r9vv] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10076) Bump netty dependency from 4.1.68.Final to 4.1.86.Final
[ https://issues.apache.org/jira/browse/OAK-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Dulceanu updated OAK-10076: -- Fix Version/s: (was: 1.22.15) > Bump netty dependency from 4.1.68.Final to 4.1.86.Final > --- > > Key: OAK-10076 > URL: https://issues.apache.org/jira/browse/OAK-10076 > Project: Jackrabbit Oak > Issue Type: Task > Components: segment-tar >Affects Versions: 1.46.0, 1.22.14 >Reporter: Andrei Dulceanu >Assignee: Andrei Dulceanu >Priority: Major > Labels: cold-standby, vulnerability > Fix For: 1.48.0 > > > *Vulnerabilities* > CVE-2022-41881 > A StackOverflowError can be raised when parsing a malformed crafted message > due to an > infinite recursion. > [https://github.com/netty/netty/security/advisories/GHSA-fx2c-96vj-985v|https://github.com/netty/netty/security/advisories/GHSA-grg4-wf29-r9vv] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10076) Bump netty dependency from 4.1.68.Final to 4.1.86.Final
Andrei Dulceanu created OAK-10076: - Summary: Bump netty dependency from 4.1.68.Final to 4.1.86.Final Key: OAK-10076 URL: https://issues.apache.org/jira/browse/OAK-10076 Project: Jackrabbit Oak Issue Type: Task Components: segment-tar Affects Versions: 1.22.14, 1.46.0 Reporter: Andrei Dulceanu Assignee: Andrei Dulceanu Fix For: 1.48.0, 1.22.15 *Vulnerabilities* CVE-2022-41881 A StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion. [https://github.com/netty/netty/security/advisories/GHSA-fx2c-96vj-985v|https://github.com/netty/netty/security/advisories/GHSA-grg4-wf29-r9vv] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10050) Enable access to the secondary Azure blobstore service endpoint in Oak segment node store
[
https://issues.apache.org/jira/browse/OAK-10050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-10050:
--
Description: Create a property for the azure segment store to enable
fallback to the secondary location
({{{}requestOptions.setLocationMode(LocationMode.PRIMARY_THEN_SECONDARY);{}}}).
> Enable access to the secondary Azure blobstore service endpoint in Oak
> segment node store
> -
>
> Key: OAK-10050
> URL: https://issues.apache.org/jira/browse/OAK-10050
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-azure
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Fix For: 1.48.0
>
>
> Create a property for the azure segment store to enable fallback to the
> secondary location
> ({{{}requestOptions.setLocationMode(LocationMode.PRIMARY_THEN_SECONDARY);{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
