ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Fwd: IgniteConfiguration.setNodeId() usage clarification
Date Thu, 06 Aug 2015 18:18:23 GMT
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 <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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message