[
https://issues.apache.org/jira/browse/OAK-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024095#comment-15024095
]
Stefan Egli commented on OAK-3672:
----------------------------------
possible ways to persist the clusterView.id include:
# store a properties file in the file system containing just this id
# store a hidden property in the repository
problem with 1 is cold-standby which would have to propagate this to the
standby node too
problem with 2 is usability when a user copies a repository that id would
automatically come with the copy, thus you'd have two clusters with the same
id. to avoid this, the user would have to be educated how this could be
deleted, which seems non-trivial if the property is stored in the repository
> SegmentDiscoveryLiteService does not persist clusterView.id
> -----------------------------------------------------------
>
> Key: OAK-3672
> URL: https://issues.apache.org/jira/browse/OAK-3672
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Affects Versions: 1.3.10
> Reporter: Stefan Egli
> Fix For: 1.3.11
>
>
> The discovery-lite-descriptor introduced with OAK-2844 has a property {{id}}
> that uniquely and persistently identifies a cluster. However, the
> {{SegmentDiscoveryLiteService}} creates this id upon each instance restart
> (by setting {{runtimeClusterId}}).
> This should be fixed to have this {{id}} persisted somehow.
> Note that the consequences of this id changing upon each restart is that the
> corresponding presumed-to-be-persistent {{ClusterView.id}} of the
> discovery.oak will also change upon restart. Which is a violation of the
> discovery API and upper level applications might thus misbehave in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
