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