ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Fwd: IgniteConfiguration.setNodeId() usage clarification
Date Mon, 10 Aug 2015 06:43:09 GMT
See below

On 8/6/2015 9:18 PM, Valentin Kulichenko wrote:
> Agree, let's move it to dev list :)
> Igniters,
> This user@ thread and points brought by Andrey clearly show that there's a
> confusion here. In my understanding, we should make clear separation: node
> ID is always uniquely generated on node start, while consistent ID survives
> restarts.
> Actually, I'm not sure how discovery will behave if a node restart with the
> same ID. Most likely there are scenarios when the coordinator will treat
> this node as already failed and will ignore messages from it. Can anyone
> confirm?
Every server node has a set of failed nodes where node ID is used to 
track such nodes.
Once a node is failed it will be always ignored as I see in the code.

> Anyway, I think we should deprecate setNodeId() configuration in favor of
> new setConsistentId(). Thoughts/objections?
> -Val
> ---------- Forwarded message ----------
> From: Andrey Kornev <andrewkornev@hotmail.com>
> Date: Thu, Aug 6, 2015 at 7:52 AM
> Subject: RE: IgniteConfiguration.setNodeId() usage clarification
> To: "user@ignite.incubator.apache.org" <user@ignite.incubator.apache.org>
> Val,
> It does make sense, thanks.
> However, in my last post I was wondering if it wasn't already possible to
> achieve the same result (of having a node consistently taking ownership of
> the same cache partitions after restarts) in the current release of Ignite
> without requiring the addition of setConsistentId? My idea was to configure
> RendezvousAffinityFunction with AffinityNodeIdHashResolver (provided by
> Ignite out-of-the-box) instead of AffinityNodeAddressHashResolver used by
> default. I'd then be able to achieve the desired effect by consistently
> setting the same node id using the regular IgniteConfiguration.setNodeId()
> (for example, from a system property) even if the node is restarted on a
> different physical machine (or if more than one JVM is started on the same
> physical box).
> Maybe this discussion is more appropriate for the dev list, but I think the
> introduction of yet another way to set a node id, namely, setConsistentId,
> is unnecessary (given the approach above works) and is bound to cause
> confusion.
> Regards
> Andrey
>> Date: Wed, 5 Aug 2015 18:48:17 -0700
>> From: valentin.kulichenko@gmail.com
>> To: user@ignite.incubator.apache.org
>> Subject: Re: IgniteConfiguration.setNodeId() usage clarification
>> Andrey,
>> In current default configuration affinity is already based on address/port
>> pair, not node ID, and therefore should survive node restarts. You can
> also
>> provide your own hash ID resolver to customize this (e.g. use some special
>> node attribute): RendezvousAffinityFunction.setHashIdResolver()
>> setConsistentId() property that will appear in next release only
> simplifies
>> this process - you will not need to implement the whole resolver if you
> just
>> want to replace address/port with a different value.
>> Makes sense?
>> -Val
>> --
>> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/IgniteConfiguration-setNodeId-usage-clarification-tp818p835.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

View raw message