[jira] [Updated] (OAK-762) MongoMK: automatic unique cluster id with few bits

["Michael Marth (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Marth updated OAK-762:
------------------------------

    Fix Version/s: 0.13

> 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)