ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vyacheslav Daradur <daradu...@gmail.com>
Subject Re: Sort nodes in the ring in order to minimize the number of reconnections
Date Tue, 27 Dec 2016 14:07:54 GMT
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.scherbakoff@gmail.com>:

> 2016-12-27 10:42 GMT+03:00 Yakov Zhdanov <yzhdanov@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message