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