My JIRA account is: Username:sharplerFull Name:Alexander Menshikov 2016-12-27 17:22 GMT+03:00 Александр Меньшиков <sharple...@gmail.com>:
> 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 >> > >> > >
