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
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
> Tests: http://ci.igni
Done. Please look.
JIRA: https://issues.apache.org/jira/browse/IGNITE-4501
PR: https://github.com/apache/ignite/pull/1436/files
Tests: http://ci.ignite.apache.org/project.html?projectId=IgniteTes
ts&tab=projectOverview&branch_IgniteTests=pull/1436/head
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 "nextNode"
Alexander, maybe you should use presorted collection in
TcpDiscoveryNodesRing.nextNode instead of iterating through unsorted one
every time?
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 system property.
>
>
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 via system property.
>
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 sho
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 ha
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 att
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 cons
Alexander, sounds good! Please post updates to ticket and this thread (if
necessary) while working.
--Yakov
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?
>
Guys, I have updated the ticket.
Alexander Menshikov, when do you expect the implementation to be finished?
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. Ima
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
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 goes for
> subnets,
> >
My JIRA account is:
Username:sharplerFull Name:Alexander Menshikov
2016-12-27 17:22 GMT+03:00 Александр Меньшиков :
> 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
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
>
> Alex Menshikov, maybe
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 Yakov Zhdanov :
>
> > >>
> > My mai
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 think the NodeComparator a
>>
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
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
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 :
> 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 or
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 nod
> 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 ca
>>
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
>>
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
reconn
>>
I thought of latency values.
Latency between host nodes < Latency between same rack nodes < Latency
between subnet nodes < etc.
>>
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 t
> 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 the
>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 su
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 Zhdan
>>
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 < e
>>
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
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
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 operations.
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
reques
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 :
> I think having some
I think having some user-defined ordering can be beneficial. However, we
are only talking about node discovery protocol here to maintain the
cluster. All other communication between nodes happens directly (does not
go through the ring).
D.
On Thu, Dec 22, 2016 at 6:32 AM, Vyacheslav Daradur
wrot
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
-
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
41 matches
Mail list logo
