>> 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. 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. 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. --Yakov
