Hi Alex, you propose to set not an affinity function, but some POJO affinity > configuration
Yes, it's exactly what I'm proposing. >From API point of view, it looks the same as just using the "partitions > count" field, but more complicated 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. If we implement ClientCacheConfiguration#setPartitions(), we may later be forced to implement other affinity-related methods directly in ClientCacheConfiguration (such as setExcludedNeighbors), which would be the wrong place for them. I understand that our disagreement is about whether we should maintain consistent UX between nodes and thin clients. IMO, we should. Thanks, Maksim On Fri, Mar 6, 2026 at 8:57 AM Alex Plehanov <[email protected]> wrote: > > Maksim, > > As far as I understand you propose to set not an affinity function, > but some POJO affinity configuration. From API point of view, it looks > the same as just using the "partitions count" field, but more > complicated. It doesn't make API consistent with Ignite node (affinity > configuration != affinity function), and currently only the > "partitions count" field is worth including to this configuration. > Field "type" (type="Rendevouz") - is redundant, because we have only > one implementation of built-in function, and if we want something not > built-in, then we need to serialize it entirely, since it can contain > parameters, not specified by our affinity configuration. > > чт, 5 мар. 2026 г. в 19:19, Maksim Timonin <[email protected]>: > > > > Hi Alex, > > > > ClientRendezvousAffinityFunction is an implementation of AffinityFunction > > > > > > Intentionally not. The thin client does not execute affinity logic locally > > — partition assignment always happens on the server. Note that > > ClientCacheConfiguration is also not a subclass of CacheConfiguration, and > > that is not considered a problem. Client and server APIs are separate > > layers connected by a protocol, not by inheritance. > > > > How and where will it be mapped to a real affinity function? > > > > > > In ClientCacheConfigurationSerializer. > > > > How will we serialize it? > > > > > > Field by field. Like (type="Rendevouz", partCnt=256...). No need for binary > > representation, predefined "type" is enough. > > > > What if the user provides their own implementation > > > > > > It will not be supported, and that is by design. Such a request fails > > during protocol validation. Only built-in affinity is allowed. > > > > On Thu, Mar 5, 2026 at 2:57 PM Alex Plehanov <[email protected]> > > wrote: > > > > > Maksim, > > > > > > ClientRendezvousAffinityFunction is an implementation of > > > AffinityFunction interface? If not, API will be inconsistent again, > > > but much more complicated. If yes, why do we need additional layer > > > instead of using standard affinity? > > > How and where it will be mapped to a real affinity function? > > > How does this change affect protocol? What fields should be added? In > > > case of standard affinity - one object field can be added (binary > > > representation of affinity) in case of partitions count - one int > > > field can be added. In case of a new entity how will we serialize it? > > > What if the user provides their own implementation? How will it be > > > mapped to real affinity? > > > > > > For me it brings a lot more inconsistency than any of the solutions > > > mentioned before. > > > > > > чт, 5 мар. 2026 г. в 13:54, ткаленко кирилл <[email protected]>: > > > > > > > > Hi. > > > > > > > > We can make the approach even more flexible by passing cache creation > > > parameters as Map<String, String>. Define an affinity function creation > > > handler on the server side and configure it, for example, in > > > IgniteConfiguration or as a plugin. By default, an affinity rendezvous will > > > be created with all the necessary parameters. > > > > > > > > Wdyt? > > >
