Fwd: IgniteConfiguration.setNodeId() usage clarification

[Valentin Kulichenko]

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?

Anyway, I think we should deprecate setNodeId() configuration in favor of
new setConsistentId(). Thoughts/objections?

-Val

---------- Forwarded message ----------
From: Andrey Kornev <[hidden email]>
Date: Thu, Aug 6, 2015 at 7:52 AM
Subject: RE: IgniteConfiguration.setNodeId() usage clarification
To: "[hidden email]" <[hidden email]>


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: [hidden email]
> To: [hidden email]
> 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.

[dsetrakyan]

On Thu, Aug 6, 2015 at 11:18 AM, Valentin Kulichenko <
[hidden email]> wrote:


> Anyway, I think we should deprecate setNodeId() configuration in favor of
> new setConsistentId(). Thoughts/objections?
>

+1

Does anyone have any objections with this approach?

D.

[Denis Magda]

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.

--
Denis

>
> Anyway, I think we should deprecate setNodeId() configuration in favor of
> new setConsistentId(). Thoughts/objections?
>
> -Val
>
> ---------- Forwarded message ----------
> From: Andrey Kornev <[hidden email]>
> Date: Thu, Aug 6, 2015 at 7:52 AM
> Subject: RE: IgniteConfiguration.setNodeId() usage clarification
> To: "[hidden email]" <[hidden email]>
>
>
> 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: [hidden email]
>> To: [hidden email]
>> 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.