[
https://issues.apache.org/jira/browse/OAK-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938422#comment-16938422
]
Marcel Reutegger commented on OAK-8593:
---------------------------------------
There's another, maybe just minor, compatibility problem I see. Consider a two
node cluster with A and B. Both are on a version without this feature. Node B
is stopped and an oak-run command with this feature uses the currently inactive
clusterId from B and set the invisible flag to true. After the command finishes
the invisible flag is still set to true. When B is started again (with the
version without this feature), the invisible flag will still be true. When the
cluster is upgraded and A is restarted with the new version, it will consider B
as invisible until B is updated to the new version as well.
So, I'm wondering whether the invisible flag should be removed when the
clusterId is released.
> Enable a transient cluster-node to connect as invisible to oak discovery
> ------------------------------------------------------------------------
>
> Key: OAK-8593
> URL: https://issues.apache.org/jira/browse/OAK-8593
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
> Reporter: Amit Jain
> Assignee: Amit Jain
> Priority: Major
> Attachments: OAK-8593-2.patch, OAK-8593.patch
>
>
> Currently, if Oak is initialized with read-write access to the DocumentStore
> (Mongo/RDB) e.g through oak-run, it is made visible to upper layers (e.g.
> sling discovery) via the oak discovery cluster view. This can cause problems
> in the actual cluster with the differing topology view and the capabilities
> advertised and in some circumstances being made a leader.
> In an offline discussion with [~mreutegg] and [~egli] it was decided that its
> best to expose a flag \{{invisible}} in the cluserNodes collection/table with
> which these instances can connect and then these would be ignored by the oak
> discovery.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
