Pavel, The idea here is that optimization will be applicable only for well-known affinity functions. E.g., we know that for rendezvous affinity, partition is "hash(key) % partitions". This is all we need to make default affinity work.
On Thu, Jun 14, 2018 at 11:41 AM, Pavel Tupitsyn <ptupit...@apache.org> wrote: > AffinityFunction interface has the following method: > int partition(Object key) > > User calls cache.put(x,y) from the client. > > In order to calculate the target node we have to call that partition > method, > and then use partition map to get the node by partition. > > But client does not have AffinityFunction. > Where am I wrong here? > > On Thu, Jun 14, 2018 at 10:26 AM, Igor Sapego <isap...@gridgain.com> > wrote: > > > Denis, that's right. > > > > Best Regards, > > Igor > > > > > > On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <dma...@apache.org> wrote: > > > > > Pavel, > > > > > > Most likely the client will be pulling the partitioning map > periodically. > > > If the local map is outdated, it won't be a big deal because a server > > node > > > that receives a request: > > > > > > - can redirect it to a map that owns a partition > > > - will add an updated partition map to the client's response or will > > > turn a special flag in the response suggesting the client do that > > > manually. > > > > > > Igor, is this what you're suggesting? > > > > > > -- > > > Denis > > > > > > On Wed, Jun 13, 2018 at 11:31 AM Pavel Tupitsyn <ptupit...@apache.org> > > > wrote: > > > > > > > Hi Igor, > > > > > > > > How can we invoke the affinity function on the client, if we don't > have > > > the > > > > implementation at hand? > > > > Am I missing something? > > > > > > > > Thanks, > > > > Pavel > > > > > > > > > > > > On Wed, Jun 13, 2018 at 5:34 PM, Igor Sapego <isap...@apache.org> > > wrote: > > > > > > > > > Hi, Igniters, > > > > > > > > > > Currently, I'm working on the thin C++ client implementation. > > > > > As you may already know, there is an issue with latency in our > > > > > thin clients, which also can result in performance issues (you > > > > > can see the "About Ignite Thin client performance" thread on > > > > > user list). > > > > > > > > > > So, how about we implement some kind of "Best Effort Affinity" > > > > > for our thin clients? In my opinion, this could be possible and > > > > > may improve mean latency when using thin clients dramatically. > > > > > > > > > > The scenario is following: > > > > > 1. Thin client connects to one of the node from the provided > > > > > address list, just as now. > > > > > 2. When user create instance of CacheClient, thin client > > > > > requests partition mapping for the cache. > > > > > 3. Client establishes connections to nodes, which are both in the > > > > > list, provided by user and in a server node response. > > > > > 4. When user makes put/get/some other cache operation, > > > > > thin client makes the best effort to send the request to the node, > > > > > which stores the data. > > > > > 5. To update partition mapping, thin client can provide public API, > > > > > or do it with some timeout. Also, we can add "miss" flag to cache > > > > > operation response, which whill indicate, that operation was not > > > > > local for the server node and which thin client can use to > > > > > understand, that partition mapping has changed to request server > > > > > node for an update. > > > > > > > > > > What do you think? > > > > > > > > > > Best Regards, > > > > > Igor > > > > > > > > > > > > > > >
