2016-12-27 10:42 GMT+03:00 Yakov Zhdanov <yzhda...@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 ordering. It's just of one of possible NodeComparator implementations. Let's not bother this it right now. > > --Yakov > -- Best regards, Alexei Scherbakov
