IgniteConfiguration.setNodeId() usage clarification

classic Classic list List threaded Threaded
7 messages Options
avk avk
Reply | Threaded
Open this post in threaded view
|

IgniteConfiguration.setNodeId() usage clarification

Hello,

Could somebody please explain the use case for setting the node id manually on the configuration object? I'm guessing it has something to do with the placement of the node on the consistent hash ring, but would like to hear from the experts.

Thanks
Andrey
vkulichenko vkulichenko
Reply | Threaded
Open this post in threaded view
|

Re: IgniteConfiguration.setNodeId() usage clarification

Andrey,

This configuration property is there just in case you want to set your own ID instead of creating a random one, it's not used in vast majority of use cases.

There is also setConsistentId() property which has to survive node restarts (by default it's a pair of hostname and port). This one is used by affinity functions.

BTW, consistent hashing is not used anymore. We have RendezvousAffinityFunction and FairAffinityFunction instead.

-Val
avk avk
Reply | Threaded
Open this post in threaded view
|

Re: IgniteConfiguration.setNodeId() usage clarification

Val,

I can't seem to be able to find the class that provides setConsistentId() method. I checked the latest code as well as the 1.3.2 release...

Could you please point me in the right direction?

Thanks
Andrey
yakov yakov
Reply | Threaded
Open this post in threaded view
|

Re: IgniteConfiguration.setNodeId() usage clarification

Ability to set consistentId will appear in next release.

--Yakov

2015-08-05 18:21 GMT+03:00 avk <[hidden email]>:
Val,

I can't seem to be able to find the class that provides setConsistentId()
method. I checked the latest code as well as the 1.3.2 release...

Could you please point me in the right direction?

Thanks
Andrey



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/IgniteConfiguration-setNodeId-usage-clarification-tp818p827.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

avk avk
Reply | Threaded
Open this post in threaded view
|

Re: IgniteConfiguration.setNodeId() usage clarification

Wouldn't I be able to achieve the same result with the current release by configuring RendezvousAffinityFunction with AffinityNodeIdHashResolver and then providing a node id (via IgniteConfiguration.setNodeId()) that survives node restart?

Thanks
Andrey
vkulichenko vkulichenko
Reply | Threaded
Open this post in threaded view
|

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
avk avk
Reply | Threaded
Open this post in threaded view
|

RE: IgniteConfiguration.setNodeId() usage clarification

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.