exposing clusterId & activeClusterNodes

[Stefan Egli <st...@apache.org>]

Hi all,

In Sling the discussion came up to leverage oak documentNodeStore's
knowledge about the state of the cluster (ie 'activeClusterNodes' from [0]
and [1]) and use that as the base for discovery ([2] and [3]). Basically,
the 'activeClusterNodes' would become the 'view of cluster nodes' that
sling's discovery would report further up the stack.

When looking at implementing this, the question is how this information is
best shared between oak-core and sling.discovery.
1. One way would be to use plain JMX (by doing a query for that
DocumentNodeStoreMBean and reading the attribute 'ActiveClusterNodes')
2. Other variants could be a more explicit API for this, via either a new
interface or some service callbacks
One issue with this is also that it would only work for documentnodestore ­
while that is the only one that has cluster implementations atm, in theory
segmentnodestore could also be implemented in a cluster. At which point the
question would be: how would we deal with the segment case. So ideally ­ if
we come up with a new interface/API on the oak level for this ­ it would be
independent of the nodestore implementation.

What's the opinion of ppl on this list ­ should we go for variant 1 or 2?

Cheers,
Stefan
--
[0] - https://issues.apache.org/jira/browse/OAK-2597
[1] - 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/o
rg/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreMBean.java
[2] - http://sling.markmail.org/thread/rrodyxlxoiuyx74d
[3] - https://issues.apache.org/jira/browse/SLING-4603

Re: exposing clusterId & activeClusterNodes

[Chetan Mehrotra <ch...@gmail.com>]

I would prefer that for now we continue ahead with existing JMX based
support and see how on Sling side it shapes up. It would give us
better understanding of how the api should look like. Once we have a
working model then we can expose a proper API meeting those
requirement.

For JMX you can just copy the current interface and use the JMX type
safe proxy support [1]

Chetan Mehrotra
[1] https://weblogs.java.net/blog/emcmanus/archive/2006/07/creating_typesa.html


On Wed, Apr 15, 2015 at 2:04 PM, Stefan Egli <st...@apache.org> wrote:
> Hi all,
>
> In Sling the discussion came up to leverage oak documentNodeStore's
> knowledge about the state of the cluster (ie 'activeClusterNodes' from [0]
> and [1]) and use that as the base for discovery ([2] and [3]). Basically,
> the 'activeClusterNodes' would become the 'view of cluster nodes' that
> sling's discovery would report further up the stack.
>
> When looking at implementing this, the question is how this information is
> best shared between oak-core and sling.discovery.
> 1. One way would be to use plain JMX (by doing a query for that
> DocumentNodeStoreMBean and reading the attribute 'ActiveClusterNodes')
> 2. Other variants could be a more explicit API for this, via either a new
> interface or some service callbacks
> One issue with this is also that it would only work for documentnodestore ­
> while that is the only one that has cluster implementations atm, in theory
> segmentnodestore could also be implemented in a cluster. At which point the
> question would be: how would we deal with the segment case. So ideally ­ if
> we come up with a new interface/API on the oak level for this ­ it would be
> independent of the nodestore implementation.
>
> What's the opinion of ppl on this list ­ should we go for variant 1 or 2?
>
> Cheers,
> Stefan
> --
> [0] - https://issues.apache.org/jira/browse/OAK-2597
> [1] -
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/o
> rg/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreMBean.java
> [2] - http://sling.markmail.org/thread/rrodyxlxoiuyx74d
> [3] - https://issues.apache.org/jira/browse/SLING-4603
>
>
>