Re: Sort nodes in the ring in order to minimize the number of reconnections

Guys, I have just commented in the ticket. I suggest to unschedule IGNITE-4501 from 2.1. Let's return to it at some point. Thanks! --Yakov

Re: Sort nodes in the ring in order to minimize the number of reconnections

Need to do code review until February 17, if we want to get this feature in version 1.9. 2017-02-08 22:14 GMT+03:00 Александр Меньшиков : > Done. Please look. > > JIRA: https://issues.apache.org/jira/browse/IGNITE-4501 > PR: https://github.com/apache/ignite/pull/1436/files

Re: Sort nodes in the ring in order to minimize the number of reconnections

Igor, I have thought about approach what you are talking about. It need add new field named like "sortedNodes" with custom ordering, which will have the same items as "nodes" field, because "nodes" has being used with default ordering in other methods. It have this advantages: 1. Method

Re: Sort nodes in the ring in order to minimize the number of reconnections

Alexander, maybe you should use presorted collection in TcpDiscoveryNodesRing.nextNode instead of iterating through unsorted one every time?

Re: Sort nodes in the ring in order to minimize the number of reconnections

Yakov, I changed the implementation. Please, look at my code again. https://github.com/apache/ignite/pull/1436 2017-01-19 15:37 GMT+03:00 Yakov Zhdanov : > Alexander, as far as I remember we talked about having cluster id set via > TcpDiscoverySpi configuration and also via

Re: Sort nodes in the ring in order to minimize the number of reconnections

I agree with Yakov. Having an integer as region ID should be sufficient to support all the use cases. On Thu, Jan 19, 2017 at 4:37 AM, Yakov Zhdanov wrote: > Alexander, as far as I remember we talked about having cluster id set via > TcpDiscoverySpi configuration and also

Re: Sort nodes in the ring in order to minimize the number of reconnections

Alexander, as far as I remember we talked about having cluster id set via TcpDiscoverySpi configuration and also via system property. What do you mean by "existence of sufficient comparator"? If we require that attribute is integer then we don't have any problems. If it is not integer then you

Re: Sort nodes in the ring in order to minimize the number of reconnections

Yakov, as I understand it we need add CLUSTER_REGION_ID for each nodes in config file. And in fact using some kind of sort in nextNode method (the search for extreme values to be exact). And the existence of valid comparator is a sufficient condition to sort nodes to build new correct ring. So I

Re: Sort nodes in the ring in order to minimize the number of reconnections

Alexander, I was against any comparator and user defined logic exactly for reason that comparison may be inconsistent. After long discussion and consensus you implement approach with comparator. Can you please explain why you did not just add logic to compare the value of CLUSTER_REGION_ID node

Re: Sort nodes in the ring in order to minimize the number of reconnections

I done that things: -- Add to TcpDiscoverySpi field Comparator nodeComparator for load custom comparators from config file like bean. -- Add implementation with old behavior: BaseNodeComparator -- Add region id implementation: RegionNodeComparator which get map from IP address to region ID in

Re: Sort nodes in the ring in order to minimize the number of reconnections

Alexander, sounds good! Please post updates to ticket and this thread (if necessary) while working. --Yakov

Re: Sort nodes in the ring in order to minimize the number of reconnections

I think that in the weeks after the 'new year' holidays or sooner. 2016-12-29 13:28 GMT+03:00 Yakov Zhdanov : > Guys, I have updated the ticket. > > Alexander Menshikov, when do you expect the implementation to be finished? >

Re: Sort nodes in the ring in order to minimize the number of reconnections

Guys, I have updated the ticket. Alexander Menshikov, when do you expect the implementation to be finished?

Re: Sort nodes in the ring in order to minimize the number of reconnections

I am OK with CLUSTER_REGION_ID. However I would like this name - DISCOVERY_REGION_ID - more. >> Do you think we will ever care about the order of nodes within the same region, e.g. does the order of nodes within the same rack matter? >> I think this is too much, but if you care you still can.

Re: Sort nodes in the ring in order to minimize the number of reconnections

Actually, after giving it some thought, I now think that the same kind of flexibility can be achieved by giving multiple nodes the same CLUSTER_REGION_ID (don't like the arc id). For example, nodes in 2 racks could be given CLUSTER_REGION_ID of 1 and 2. This way all nodes in rack 1 or rack 2 would

Re: Sort nodes in the ring in order to minimize the number of reconnections

On Tue, Dec 27, 2016 at 2:32 AM, Alexei Scherbakov < alexey.scherbak...@gmail.com> wrote: > 2016-12-27 10:42 GMT+03:00 Yakov Zhdanov : > > I think the NodeComparator approach will work. User can chose how to sort > > nodes from one rack before nodes from another rack. Same

Re: Sort nodes in the ring in order to minimize the number of reconnections

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 : > 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 > >

Re: Sort nodes in the ring in order to minimize the number of reconnections

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

Re: Sort nodes in the ring in order to minimize the number of reconnections

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

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> 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

Re: Sort nodes in the ring in order to minimize the number of reconnections

> 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

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> 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

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> 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

Re: Sort nodes in the ring in order to minimize the number of reconnections

> I am afraid I did not understand this at all. Please elaborate. 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

Re: Sort nodes in the ring in order to minimize the number of reconnections

>Then, as I understand it, a lot of reconnection in the ring cannot create even temporary but major problems for performance. And in general this optimization will change practically nothing. Or am I missing some things? I am afraid I did not understand this at all. Please elaborate. I did not

Re: Sort nodes in the ring in order to minimize the number of reconnections

Thank you, Denis, for your explanation. Then, as I understand it, a lot of reconnection in the ring cannot create even temporary but major problems for performance. And in general this optimization will change practically nothing. Or am I missing some things? 2016-12-26 12:20 GMT+03:00 Yakov

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> Vyacheslav, please elaborate on how we can determine whether we are on the same rack. I am not sure this is possible in general case. Please see my suggestions below. >> I thought of latency values. Latency between host nodes < Latency between same rack nodes < Latency between subnet nodes <

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> For example, ordering on latency: - nodes on one host = 1 - nodes in one rack-blade = 2 - nodes in one server-rack = 3 - nodes in one physical cluster = 4 - nodes in one subnet = 5 - etc. Maybe it'll be better to use some metrics from ClusterMetrics interface. The algorithm of ordering can be

Re: Sort nodes in the ring in order to minimize the number of reconnections

Alexander, This is something different and looks unrelated to the discussion we have over here. A transaction will not be rolled back the way you’re describing. It will be either committed once or rolled back once. There can be and will be inter nodes communication when something fails at the

Re: Sort nodes in the ring in order to minimize the number of reconnections

I in fact worried about the following situation: Like i said we have ring A->F->B->E->C->D->A, and connection between A,B,C and D,E,F was been broken. But nodes will detect the fact of the unavailability of nodes not at the same time. And meanwhile the client will perform transactional

Re: Sort nodes in the ring in order to minimize the number of reconnections

Hi Vyacheslav, Discovery logic is incapsulated in TcpDiscoverySpi. TcpDiscoveryMulticastIpFinder in one of many implementations of IP finder. The only purpose of the IP finder is to provide list of addresses where a node can send initial join request, and the fact that it sends this initial

Re: Sort nodes in the ring in order to minimize the number of reconnections

Thanks for reply. I have some questions: 1. Where the logic of Ignite cluster building is realized? DiscoverySpi and TcpDiscoveryMulticastIpFinder? 2. Which standart Ignite metrics you can recommend to use for node-ordering? 2016-12-22 19:08 GMT+03:00 Dmitriy Setrakyan :

Re: Sort nodes in the ring in order to minimize the number of reconnections

Hello, Alex! I think it is a great idea. I suggest to build communications between nodes on weight (or priority). For example, ordering on latency: - nodes on one host = 1 - nodes in one rack-blade = 2 - nodes in one server-rack = 3 - nodes in one physical cluster = 4 - nodes in one subnet = 5

Sort nodes in the ring in order to minimize the number of reconnections

Hello everyone, As far as I know nodes are connected in a ring. For example if i have 6 nodes, with names A, B, C, D, E, and F they can connect in ring any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A, etc. And if some node falls out of topology neighboring nodes must reconnect. If nodes A,B and