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