[
https://issues.apache.org/jira/browse/OAK-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119160#comment-15119160
]
Stefan Egli commented on OAK-3672:
----------------------------------
As suggested on the list the way forward is to not set the id in the
SegmentDiscoveryLiteService case as all and leave the responsibility of
managing the clusterId to upper layers.
There's currently only one known upper layer and that's discovery.oak - and
returning null for the id in the discovery-lite descriptor breaks discovery.oak.
Which means, a fix of OAK-3672 requires SLING-5458 first.
> 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
> Assignee: Stefan Egli
> Fix For: 1.4
>
>
> 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)
