Hi Alex,
I'd prefer next option:
ClientCacheConfiguration cfg = new ClientCacheConfiguration();
cfg.setAffinityFunction(
new ClientRendezvousAffinityFunction()
.setPartitions(256)
);
Arguments are:
1. API consistency with CacheConfiguration. Currently,
ClientCacheConfiguration is a subset of CacheConfiguration (excluding
ExpirePolicy configuration). I think keeping the client and server
configuration classes aligned is good UX and should be preserved going
forward.
2. Partition count is a property of
AffinityFunction. RendevouzAffinityFunction also holds backupFilter,
excludeNeighbors flags. This could be supported on the client side later as
well. Flattering these options into ClientCacheConfiguration would blur the
boundary between what is and is not supported right now.
3. Having a dedicated client-side affinity function class provides a clear
mapping between client and server affinity functions, which makes it easier
to support new functions, flags, and parameters in the future.
I have a concern about the naming "ClientRendevouzAffinityFunction". Maybe
it would be better to use "RendevouzAffinityFunction" and distinguish it
from the server-side class by package name only.
Thanks,
Maksim
On Thu, Mar 5, 2026 at 12:53 PM Alex Plehanov <[email protected]>
wrote:
> Hi, Igniters!
>
> It's a common request from users to have an ability to configure cache
> partitions count through thin clients. Currently, users can solve this
> problem only by using configured on the server-side cache templates,
> but it's not always possible and not flexible enough. The problem with
> partitions count lies in the fact that it's a parameter of the
> affinity function, and the affinity function is a java class. We've
> discussed this problem with Maksim Timonin privately, but didn't come
> to a common decision.
>
> Here are options I see:
> 1. Technically, we have all possibilities to pass configured affinity
> function from clients to server, if affinity function/backup filter
> classes already on servers (in 99.99% cases built-in rendezvous
> affinity function is used, without filters or with one of built-in
> filters), using this approach we keep similarity between
> ClientCacheConfiguration and CacheConfiguration, but we also have some
> cons, for example, it's applicable only for java thin client and it's
> required to have an affinity function class on client-side.
> 2. We can include just one parameter to ClientCacheConfiguration:
> "partitions count" and create the default affinity function on
> server-side with this partitions count. In this case we add
> inconsistency between ClientCacheConfiguration and CacheConfiguration
> (btw, they already have a difference in parameters and don't have
> common superclass or interface), but reduce complexity for users.
>
> Personally, I think option 2 is better. WDYT? Any other options?
>
