Ok, let's use option 3 and two parameters (partitions count and excludeNeighbors) Thank you for your attention.
ср, 11 мар. 2026 г. в 09:57, Pavel Tupitsyn <[email protected]>: > > > do you know any usage of excludeNeighbors in production > > several server nodes are located on the same host > > It might seem strange, but it was added due to customer demand. > Yes, it is used in prod by some. > > On Wed, Mar 11, 2026 at 8:47 AM Maksim Timonin <[email protected]> > wrote: > > > > Hi, > > > > +1 for option 3. > > > > For option 4. Unlike option 3, it requires moving AffinityFunction and its > > implementations to the ignite-common module, which is shared between thin > > clients and core. This is debatable. Is it appropriate to use the > > ignite-common module for core configurations? > > > > > > > > среда, 11 марта 2026 г. пользователь Pavel Tupitsyn <[email protected]> > > написал: > > > > > 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). > > >
