Sooner or later someone will ask for "excludeNeighbors", it is an important prop and most people use rendezvous, from my experience. So I prefer option 3 or 4.
On Tue, Mar 10, 2026 at 10:03 PM Alex Plehanov <[email protected]> wrote: > > Pavel, in this implementation thin client still needs affinity > function implementation in classpath, but in case client and server > jars will be separated, rendezvous function required only in server > jar. > Also, you pass two parameters: "partition count" (part of the affinity > function interface) and "exclude neighbors" (not part of the > interface, but part of the rendezvous function). I think binding > protocol to specific affinity function implementation (even if this > implementation is the only built-in implementation) is not correct. > > Overall we have 4 proposals in this thread: > 1. Configure affinity function implementation, pass affinity function > as binary object - most flexible (all parameters can be configured, > including backup filters, custom affinity can be configured), API > compatible with thick client cache configuration, but applicable only > for java thin client and requires affinity function in client jar. > 2. Configure partitions count - client don't need to know anything > about affinity function implementation, but API not compatible with > thick client cache configuration. > 3. Configure some parameters of affinity function via new entity, pass > only these configured parameters - client doesn't require affinity > function in client's jar, API not compatible with thick client cache > configuration (requires code change, when change from thick to thin > client cache configuration) > 4. Configure affinity function implementation, pass some of parameters > of this affinity function - API compatible with thick client cache > configuration (if only supported parameters are used), requires > affinity function in client jar > > I still think that the 2nd option is the best. It's simplest and the > client doesn't need to know anything about affinity function > implementation. It makes the API less compatible with thick clients, > but we already have some incompatibility and options that are > compatible with thick clients require the affinity function > implementation in client jar. > > Guys, WDYT? > > пн, 9 мар. 2026 г. в 15:47, Pavel Tupitsyn <[email protected]>: > > > > Implemented in the fork: > > https://github.com/gridgain/gridgain/commit/22d2eb922c5f65c77342c5ed48efb3991e29a5ef > > > > On Mon, Mar 9, 2026 at 11:20 AM Pavel Tupitsyn <[email protected]> wrote: > > > > > > The simplest solution is to add support only for the existing > > > RendezvousAffinityFunction like this: > > > > > > if > > > (protocolCtx.isFeatureSupported(ClientBitmaskFeature.CACHE_CFG_AFFINITY)) > > > { > > > AffinityFunction affinity = cfg.getAffinity(); > > > if (affinity instanceof RendezvousAffinityFunction) { > > > writer.writeBoolean(true); > > > RendezvousAffinityFunction rendezvous = > > > (RendezvousAffinityFunction) affinity; > > > writer.writeInt(rendezvous.partitions()); > > > writer.writeBoolean(rendezvous.isExcludeNeighbors()); > > > } else { > > > writer.writeBoolean(false); // Or maybe throw an error > > > } > > > } > > > > > > So the API is consistent with the server side and the implementation > > > is simple enough. > > > > > > > > > On Fri, Mar 6, 2026 at 12:52 PM Alex Plehanov <[email protected]> > > > wrote: > > > > > > > > Maskim, > > > > > > > > > I propose to keep the user path for creating caches consistent for > > > > > Ignite > > > > > nodes and thin clients, because that is how it is done for all other > > > > > settings today. > > > > 1. We already have some inconsistency between nodes and thin clients > > > > (ClientCache has some difference with IgniteCache, ClientConfiguration > > > > is absolutely different to IgniteConfiguration, > > > > ClientCacheConfiguration has some difference with CacheConfiguration, > > > > etc). So "how it is done for all other settings" is not correct. > > > > 2. As I said before, your proposal has nothing to do with maintaining > > > > consistency. In node configuration we provide configured affinity. In > > > > thin client configuration we provide some parameters for affinity. > > > > It's absolutely different from the user's point of view. For example, > > > > the user can't just replace CacheConfiguration with > > > > ClientCacheConfiguration and don't change other code parts. Code > > > > related to affinity still needs to be rewritten. If so, why is it > > > > better than just "partitions count"? It has the same disadvantages > > > > (API inconsistency), but "partitions count" is simpler. Affinity > > > > configuration looks like a redundant entity, which can contain only > > > > one parameter "partitions count". > > > > 3. setExcludedNeighbors it's not a part of the affinity function > > > > interface, it's part of Rendezvous Affinity implementation (as far as > > > > node filters, backup filters, etc). If we want these parameters, it's > > > > better to provide stateful serialization of affinity (not just > > > > affinity configuration).
