Hi Felix, On 4/10/15 10:53 AM, "Felix Meschberger" <[email protected]> wrote:
> * It depends on a specific implementation detail of a specific > Oak MK/NodeStore implementation. This implementation may > change at any time > * This feature seems to be accessed through JMX which exposes > and admin interface which is not guaranteed to be stable > for regular programmatic use Agreed. (except it's a trade-off with the advantage gained, as pointed out below) > * It limits the topology to the Oak cluster members Not exactly. The idea was to use (embed) most of the functionality of discovery.impl - ie reuse the topology connectors et al. So cross-cluster would work exactly the same as with discovery.impl. > * This looks like hacking around a problem in Oak leveraging > other parts of Oak which seem to have issues in themselves Or, stated slightly differently: Oak's document-based clustering comes with an eventual consistency model. This by design incorporates a certain, undefined delay between when writes from one node become visible to others. In such a model it is unclear what, under any circumstances, the largest delay will be - and thus, what a proper heartbeat timeout should be configured to. So by making use of these ActiveClusterNodes, this 'eventual consistency' (ie its delay) can be completely avoided and thus the algorithm becomes much more deterministic. PS: Discussed this offline today with Carsten/MichaelM: we should in any case finally implement a fix for long-standing SLING-3432 - this should be a big improvement to discovery.impl - and it would apply to any discovery.* implementation. I've added a comment to SLING-3432. PPS: I'll create another follow-up ticket for discovery which will be about 'proper synchronizing between sending of topology_changed event and the fact that the underlying repository is eventual consistent'. This currently is automatically handled in discovery.impl (as it is based on the repository and thus incorporates this "eventual-ness") - but any other discovery implementation (eg etcd/zookeeper/documentnodestore-based) that circumvents the repository must watch out for this. Cheers, Stefan >All in all, I doubt whether the energy we put into this really is worth >it given there are valid other solutions around which are sound, stable, >and proven such as etcd, zookeeper. > >Maybe we should stick with the current discovery.impl as being good >enough and instead concentrate on building a new discovery implementation >based on said proven technology. For demo and ease-of-use purposes the >current discovery.impl is probably sufficient. For real world uses a etcd >or zookeeper or whathever based solution may be more promising IMHO. > >Sorry to sound deceptive, but I am not convinced of the approach. > >Just my two cents > >Regards >Felix > > >> Am 09.04.2015 um 17:29 schrieb Stefan Egli <[email protected]>: >> >> Hi all, >> >> It has come up that with discovery.impl based on oak we could make use >>of >> oak's (mongoMk's) lease mechanism instead of sending higher level >> heartbeats. >> >> I've created SLING-4603 to track that and would appreciate some opinions >> from this list. I'd be looking at providing a first implementation of >>this >> for review. >> >> Cheers, >> Stefan >> -- >> https://issues.apache.org/jira/browse/SLING-4603 >> linked to this one: https://issues.apache.org/jira/browse/SLING-2939 >> >> >
