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? > >
