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