You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2016/02/04 10:05:40 UTC

[jira] [Closed] (SLING-5458) support discovery-lite's id==null (by managing the id in discovery.oak)

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

Stefan Egli closed SLING-5458.
------------------------------

> support discovery-lite's id==null (by managing the id in discovery.oak)
> -----------------------------------------------------------------------
>
>                 Key: SLING-5458
>                 URL: https://issues.apache.org/jira/browse/SLING-5458
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions
>    Affects Versions: Discovery Oak 1.2.0
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>             Fix For: Discovery Commons 1.0.8, Discovery Oak 1.2.2
>
>
> OAK-3672 describes the fact that the (cluster) id in tarMk case is not persisted and thus doesn't survive server restarts. This breaks the discovery API contract since discovery.oak uses this id directly as the ClusterView.getId - and that must by definition be stable (across restarts that is).
> The solution suggested [on oak-dev list|http://oak.markmail.org/thread/r4o3evykrlafeimk] is to have tarMk return null for this id (while mongoMk still manages this id).
> This implies that discovery.oak must now handle the fact that the discovery-lite id is null. In which case it should readOrDefine a {{clusterId}} at {{/var/discovery/oak}}.
> This will auto-support cold standby/failover as well as not harm the repo-clone case (as this solution is equivalent to how discovery.impl is working).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)