[
https://issues.apache.org/jira/browse/OAK-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15126096#comment-15126096
]
Stefan Egli commented on OAK-3935:
----------------------------------
bq. Can we use sling's cluster id here, which will make it semantically similar?
I'm assuming you're referring to discovery API's {{ClusterView.getId()}} ?
The way this is solved in discovery.impl (for all cases) and discovery.oak (for
tarmk) is by storing a uuid under /var/discovery/... - thus cloning a
repository requires deleting this id in the cloned repo too (which is do-able
as it is not a hidden path/property). (For mongoMk this is stored in the
settings collection and there's currently no easy way to delete it should
someone clone a mongo repo. But that is less likely/frequent than cloning a
tarMk repo IMO).
bq. Can we use sling's cluster id here
So I guess yes, it can be used. With the restrictions that are applicable, such
as: the ID is not always available, especially not during startup, at which
point discovery is still busy determining a valid view. It is also not
available during topology changes - but in a tarMk there's no topology changes
relating to the local cluster (as it is by definition always 1 instance). So
basically once the initial topology is provided via {{TOPOLOGY_INIT}} (or via
{{DiscoveryService.getTopology().isCurrent()==true}}) any subsequent event can
'in theory' be ignored wrt the local cluster's id (for segment that is).
So conceptually this can be reused yes. It would of course introduce a(nother)
dependency from Oak to Sling - but if that's acceptable and optional, there's
nothing that prevents this.
> SharedDataStore - Allow unique repository ID to be specified by config
> -----------------------------------------------------------------------
>
> Key: OAK-3935
> URL: https://issues.apache.org/jira/browse/OAK-3935
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob, segmentmk
> Reporter: Amit Jain
> Assignee: Amit Jain
> Labels: resilience
> Fix For: 1.2.11, 1.3.15
>
> Attachments: OAK-3935-sling-settings.patch
>
>
> For GC in a shared DataStore, a unique repository Id is currently saved in a
> hidden path in the node store on startup and registered in the DataStore.
> This will cause problems where the publish environments are cloned and share
> a datastore.
> There should be an option to specify a unique id in the config when setting
> up the node store.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
