[jira] [Resolved] (OAK-10917) Make persistent cache related arguments optional for Azure compaction

2024-06-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-06-24 Thread Andrei Dulceanu (Jira)
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

2024-06-20 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-06-20 Thread Andrei Dulceanu (Jira)


[ 
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

2024-06-20 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-06-18 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-06-17 Thread Andrei Dulceanu (Jira)
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

2024-06-06 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-06-04 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-06-04 Thread Andrei Dulceanu (Jira)
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

2024-05-30 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-05-28 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-05-27 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-05-27 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-05-27 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-05-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-05-24 Thread Andrei Dulceanu (Jira)
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

2024-05-15 Thread Andrei Dulceanu (Jira)
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

2024-01-26 Thread Andrei Dulceanu (Jira)


[ 
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

2024-01-26 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-26 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-26 Thread Andrei Dulceanu (Jira)
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

2024-01-25 Thread Andrei Dulceanu (Jira)
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

2024-01-25 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-25 Thread Andrei Dulceanu (Jira)
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-*

2024-01-25 Thread Andrei Dulceanu (Jira)


 [ 
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-*

2024-01-25 Thread Andrei Dulceanu (Jira)
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

2024-01-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-24 Thread Andrei Dulceanu (Jira)
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

2024-01-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-24 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-24 Thread Andrei Dulceanu (Jira)
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

2024-01-24 Thread Andrei Dulceanu (Jira)


[ 
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

2024-01-23 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-22 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-22 Thread Andrei Dulceanu (Jira)
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

2024-01-19 Thread Andrei Dulceanu (Jira)
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

2024-01-19 Thread Andrei Dulceanu (Jira)
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

2024-01-18 Thread Andrei Dulceanu (Jira)


[ 
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

2024-01-18 Thread Andrei Dulceanu (Jira)
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

2024-01-18 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-18 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-18 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2024-01-15 Thread Andrei Dulceanu (Jira)
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

2024-01-15 Thread Andrei Dulceanu (Jira)
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

2023-12-22 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-12-22 Thread Andrei Dulceanu (Jira)


[ 
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

2023-12-22 Thread Andrei Dulceanu (Jira)


[ 
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

2023-12-19 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-12-19 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-12-19 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-12-19 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-12-19 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-12-19 Thread Andrei Dulceanu (Jira)
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

2023-11-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-11-14 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-10-06 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-10-05 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-10-05 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-10-02 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-22 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-20 Thread Andrei Dulceanu (Jira)


[ 
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

2023-09-20 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


[ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


[ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


[ 
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

2023-09-15 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-08-07 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-06-09 Thread Andrei Dulceanu (Jira)


[ 
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

2023-06-09 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-06-06 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-06-06 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-04-14 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-04-14 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-04-14 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-04-14 Thread Andrei Dulceanu (Jira)
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

2023-04-14 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-04-14 Thread Andrei Dulceanu (Jira)
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

2023-03-30 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-02-02 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-02-02 Thread Andrei Dulceanu (Jira)
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

2023-01-23 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-01-23 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-01-20 Thread Andrei Dulceanu (Jira)


 [ 
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

2023-01-20 Thread Andrei Dulceanu (Jira)
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

2022-12-21 Thread Andrei Dulceanu (Jira)


 [ 
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)


[jira] [Assigned] (OAK-10050) Enable access to the secondary Azure blobstore service endpoint in Oak segment node store

2022-12-21 Thread Andrei Dulceanu (Jira)


 [ 
https://issues.apache.org/jira/browse/OAK-10050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Dulceanu reassigned OAK-10050:
-

Assignee: Andrei Dulceanu

> 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
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (OAK-10050) Enable access to the secondary Azure blobstore service endpoint in Oak segment node store

2022-12-21 Thread Andrei Dulceanu (Jira)
Andrei Dulceanu created OAK-10050:
-

 Summary: 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
 Fix For: 1.48.0






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


  1   2   3   4   5   6   7   8   9   10   >