+1 to have ability to specify custom affinity for PA on thin client. It seems to me custom affinity is a rare use-case of Ignite API. Propose to have SystemProperty that can specify affinity implementation for a thin client.
> 29 июня 2022 г., в 18:53, Maxim Muzafarov <mmu...@apache.org> написал(а): > > Igniters, > > > I've faced with a customer's cluster which has more than 150 nodes and > most for them are the thick-client nodes. Due to each thick-client is > a full-fledged cluster topology participant it affects the cluster > discovery machinery during the system operation and adding an > additional overhead for using/deploying a new nodes in Kubernetes > environment. However, the main thing from my point of view it prevents > updating the client side and server side components independently > (Apache Ignite doesn't support rolling upgrade). > > Accordingly to the assumptions above using thin clients become a > necessary. This looks even more attractive, since the thin client has > a fairly rich API over the past few releases. > > > The MAIN ISSUE here that blocks thin client usage is that for some of > cache groups a custom affinity function (and an AffinityKeyMapper) was > used which prevents enabling the Partition Awareness thin client > feature. Thus each cache request will have two hops. > > Of course, we can force users to migrate to a new API, but this > becomes more difficult when Apache Ignite is part of a much larger > architectural solution and thus it is doent' looks so friendly. > > The MAIN QUESTION here - does anyone know our users who have > encountered with the same issue? I want to solve such a problem once > and make all such users happy by implementing the general approach. > > > = Possible solutions = > > > 1. Making an affinity function pluggable (mapping calculations) on the > thin clients side. Currently the RendezvousAffinityFunction [1] is > only supported > for the partition awareness. A user's affinity function seems to be > the stateless function due to there is no machinery to transfer states > to the thin client. > > Pros - a general solution for all such cases; > Cons - unnecessary complexity, extending public API; > > > 2. Creating an Ignite extension which will extend the thin client API > thus a user will have a full control over a destination node to which > requests being sent. > > Pros - isolated solution, simple implementation; > Cons - hard to support spring-boot-thin-client etc. and other > extensions based on the thin client API; > > > Folks, please share your thoughts. > > > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/cache/ClientCachePartitionsRequest.java#L206
