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.
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? D. On Mon, Dec 26, 2016 at 12:42 PM, Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > 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.scherbak...@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 Александр Меньшиков <sharple...@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 <daradu...@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 <yzhda...@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 >
