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).
