[
https://issues.apache.org/jira/browse/OAK-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Marth resolved OAK-762.
-------------------------------
Resolution: Fixed
duplo
> MongoMK: automatic unique cluster id with few bits
> --------------------------------------------------
>
> Key: OAK-762
> URL: https://issues.apache.org/jira/browse/OAK-762
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Reporter: Thomas Mueller
> Fix For: 0.13
>
>
> Currently, the cluster id of a MongoMK instance is configurable. It needs to
> be set when constructing the MongoMK instance, or by setting a system
> property. Both solutions are not nice. Instead, the cluster id should be
> automatically assigned unless explicitly set, and if explicitly set, the
> MongoMK should have a mechanism to ensure the same cluster id is not used
> multiple times concurrently.
> As the revision contains the cluster id, the cluster id should be a low
> number (ideally, the first cluster id of a cluster should be 0, the next 1,
> and so on). This would keep the size of the revision numbers low. To simplify
> support, it would be nice if the same repository uses the same cluster id
> after a restart, even thought this isn't strictly necessary.
> We could use the same or a similar algorithm as MongoDB uses for the machine
> id part of ObjectIDs.
> We could also use a persistent mapping between unique repository identifier
> and cluster id. The mapping itself could be stored in a MongoDB collection.
> The unique repository identifier (the cluster node id for Jackrabbit 2.x)
> could be the combination of the MAC address of the first network interface of
> the machine, and a guaranteed unique value within the given machine. The
> unique value could be the "repository home" directory (that would be nice as
> it survives restarts), or an incrementing number assigned by a service
> running on the given machine (so the first repository on this machine would
> get id "0", the second id "1", and so on - this would survive restarts as
> well in the common case where there is only one cluster node per machine).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
