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