[
https://issues.apache.org/jira/browse/OAK-9914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17598486#comment-17598486
]
Miroslav Smiljanic commented on OAK-9914:
-----------------------------------------
Hi [~jsedding], thanks for the comment.
{quote}Therefore, I would argue that the AzureArchiveManager mustn't throw an
exception, but should just return null.
{quote}
Returning null wouldn't allow having the second Oak process in read-only mode.
In the Azure implementation of the segment store, the archive index is always
computed when creating archive reader
[AzureSegmentArchiveReader|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.44.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/AzureSegmentArchiveReader.java#L46]
and kept in memory. So right now, the exception is thrown if "closed" blob is
missing, which makes the code higher up in the hierarchy to conclude that
something is wrong with the index, which is not the case. Constructor in
[AzureSegmentArchiveReader|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.44.0/oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/AzureSegmentArchiveReader.java#L46],
builds an in-memory index, and from there, IOException can be thrown, which is
fine.
Like [~joerghoh] , I also prefer the second approach with system property.
Something like [^AzureArchiveManager_sys_prop.patch]. Or skip checking for
"closed" blob altogether.
> Starting Oak with Azure persistence in read-only mode while another Oak
> process is running will initiate repo recovery
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: OAK-9914
> URL: https://issues.apache.org/jira/browse/OAK-9914
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: segment-azure
> Affects Versions: 1.44.0
> Reporter: Miroslav Smiljanic
> Assignee: Miroslav Smiljanic
> Priority: Major
> Attachments: AzureArchiveManager.patch,
> AzureArchiveManager_sys_prop.patch, OAK-9914_test.patch
>
>
> The sequence of events:
> # Oak process with read/write file store utilizing Azure persistence is
> already running
> # New Oak process is starting up, with read-only file store using Azure
> persistence and the same storage account and container like the previous Oak
> process
> ## New Oak process starts recovery procedure for the last tar directory that
> is not closed
> Scenario presented in the attached test case:
> [^OAK-9914_test.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
