[
https://issues.apache.org/jira/browse/OAK-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200154#comment-16200154
]
Amit Jain commented on OAK-6802:
--------------------------------
bq. it might be possible that each one would have its own secret.
The initialization does not depend on the server startup time but the first
call to getOrCreateReferenceKey(). While there's a theoretical possibility that
what is stored is different what was sent to be written I am not sure that is a
cause of concern ultimately the secret in memory would be different. Also, we
can do a re-read to obtain what was stored and use that as the key as S3
ensures that only 1 object would obtain the key. (I am not sure about the Azure
behavior here).
bq. should the record inputstream be closed after the data was read
Yes it could be problem on exception and socket connection handles might be
left open.
> Manage 'secret' property internally in S3/AzureDataStore
> --------------------------------------------------------
>
> Key: OAK-6802
> URL: https://issues.apache.org/jira/browse/OAK-6802
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob-cloud, blob-cloud-azure
> Reporter: Amit Jain
> Assignee: Amit Jain
> Fix For: 1.8
>
>
> Property 'secret' is required to be configured (which is a shared secret
> among instances sharing the datastore) to enable binary-less replication. The
> DataStore should manage it internally as it does for other things in the META
> folder like in the container like repository ID etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
