ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Scherbakov <alexey.scherbak...@gmail.com>
Subject Re: Sort nodes in the ring in order to minimize the number of reconnections
Date Tue, 27 Dec 2016 10:32:45 GMT
2016-12-27 10:42 GMT+03:00 Yakov Zhdanov <yzhdanov@apache.org>:

> >>
> My main concern here is code complexity. Yakov, how difficult it is to
> stick a new node in an arbitrary spot of a discovery ring?
> >>
> Dmitry, I think this is not hard. At least I don't see any issue now.
> >>
> I think the NodeComparator approach will work. User can chose how to sort
> nodes from one rack before nodes from another rack. Same goes for subnets,
> or data centers.
> >>
> Dmitry, can you please explain why you enforce user to write code? This
> does not seem convenient to me at all. If user wants to write code then he
> can do it for calculating proper arc_id.

Yakov, where is no need to for user to write code. We can provide two
default Comparator implementations:
first based on IP address(default), and second based on node attribute.
User just plugs one of the implementations and adds node attribute to node
config in second case - let it be ARC_ID by default.

> Another point I already posted to this thread - this is very error prone.
> >>
> I am strongly against giving user an opportunity to point exact place in
> the ring with somewhat like this interface [int getIdex(Node newNode,
> List<Node> currentRing)]. This is very error prone and may require tricky
> consistency checks just to make sure that implementation of this interface
> is consistent along the topology.
> With "arcs" approach user can automatically assign proper ids basing on
> physical network topology and network routes.
> >>
> I still think arc_id is better:
> 1. No code from user side. Only env variable or system property on a
> machine.
> 2. All code inside Ignite - easy to fix and change if required.
> 3. All benefits of comparator are still available.

I suppose my approach is more generic and also matches listed requirements.

> Alex, I still don't get how you (and other guys as well) want to deal with
> latencies here. I would like you explain how you solve this - you have 1000
> IP addresses, and you need to sort them in your beloved latency order, but
> please note that you need to get exactly the same ring on all of these 1000
> machines.

Calculating latencies are beyond scope of generic approach of nodes
It's just of one of possible NodeComparator implementations.
Let's not bother this it right now.

> --Yakov


Best regards,
Alexei Scherbakov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message