ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Scherbakov <alexey.scherbak...@gmail.com>
Subject Re: Sort nodes in the ring in order to minimize the number of reconnections
Date Mon, 26 Dec 2016 20:42:20 GMT
Of course where is no need to sort all nodes.

It's enough just to select smallest node.

2016-12-26 22:29 GMT+03:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:

> Yakov,
>
> ARC_ID approach seems just a variation of node attribute based ordering
> for me.
>
> I suggest more generic approach.
>
> What if we define node ordering using something like NodeComparator?
>
> Then a new node joins topology, it calculates node for joining using
> sorting on current topology + new node.
>
> nextNode just takes first element in sorted list. It's guaranteed what all
> nodes will return the same sorted list for the topology version.
>
> We can provide default implementation based on IP address:
>
> nodes on the same host : nodes on the same subnet : other nodes
>
> I think this will work for most cases.
>
> If needed user can provide it's own comparison strategy based on
> latencies, data centers, whatever.
>
>
>
>
>
>
>
> 2016-12-26 17:17 GMT+03:00 Александр Меньшиков <sharplermc@gmail.com>:
>
>> > Can you please explain why this is better than arc approach?
>>
>> We had a misunderstanding. Everything okay with arc approach. But we must
>> choose how nodes will determine "ARC_ID", and i think it can be calculated
>> from latency values. If users will be able to set "ARC_ID" in config file
>> then they can set different 'ARC_ID' on all nodes, and, in fact, point
>> exact place in the ring, what we would like to avoid.
>>
>> 2016-12-26 15:36 GMT+03:00 Vyacheslav Daradur <daradurvs@gmail.com>:
>>
>> > >>
>> > Vyacheslav, I agree that latency increase in the way you describe, but I
>> > still don't understand how we use this information in discovery. Latency
>> > may differ from time to time depending on many factors. I still think
>> that
>> > arc approach is more intuitive for user and easier to implement.
>> > >>
>> >
>> > Way of latency increase is just a main idea.
>> >
>> > I suggest to connect new node on some priority.
>> > General approach:
>> > --
>> > if [ there are same host node ] then [ connect with it ]
>> > else if [ there are same subnet nodes] then [ connect with one of them ]
>> >  // how to choose node from a set of subnet? - choose with min latency
>> each
>> > other
>> > else [ connect to remote nodes ] // how to choose node from a set of
>> > remotes? - choose with min latency each other
>> > --
>> > Maybe we can describe another intermediate steps.
>> >
>> >
>> > 2016-12-26 15:08 GMT+03:00 Yakov Zhdanov <yzhdanov@apache.org>:
>> >
>> > > >>
>> > > I just want to understand which benefits we get when implement what
>> we're
>> > > talking about. If major benefit is reduced latency of ring messages,
>> then
>> > > the assignment 'ARC ID' in accordance with latency value is quite
>> > > enough. But if there are any hidden problems because of the large
>> number
>> > of
>> > > reconnection (like I described in first message in this discussion),
>> then
>> > > better to find a way to determine real physical location.
>> > > >>
>> > >
>> > > I suggest to solve ring building up and reducing number of reconnects
>> > > separately. If we have AxB-C-D-A then A will try to reconnect to B,
>> then
>> > to
>> > > C, then to D. This is how discovery works now. I agree this should be
>> > fixed
>> > > and I have couple ideas on how we can do it but let's separate these
>> > ones.
>> > >
>> > > >>
>> > > Okey, then i think Vyacheslav's idea (using latency values) is quite
>> > enough
>> > > when we can't determine real physical location.
>> > > >>
>> > >
>> > > Can you please explain why this is better than arc approach?
>> > >
>> > > --Yakov
>> > >
>> >
>>
>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>



-- 

Best regards,
Alexei Scherbakov

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