[
https://issues.apache.org/jira/browse/OAK-9914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599482#comment-17599482
]
Julian Sedding commented on OAK-9914:
-------------------------------------
[~joerghoh] Yes the change I propose would change the behaviour of
oak-segment-azure slightly. It would align it with (my interpretation) of the
javadocs and with the implementation of oak-segment-tar (which I consider the
canonical implementation). The change doesn't introduce any test failures and I
assume the only consumers of this internal API catch the exception and handle
it as if it were null. On a practical level, returning null avoids the
stack-trace being printed to the logs, which IIUC was part of the problem.
> 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)
