Yes, i can. But someone needs to give me the rights of contributor in Jira.
2016-12-27 17:07 GMT+03:00 Vyacheslav Daradur <daradu...@gmail.com>: > 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 > > >
