I have described a task: https://issues.apache.org/jira/browse/IGNITE-4501
and linked a bug https://issues.apache.org/jira/browse/IGNITE-4499 Alex Menshikov, maybe you will take her? 2016-12-27 13:32 GMT+03:00 Alexei Scherbakov <alexey.scherbak...@gmail.com>: > 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 >
