Folks, Feel that this functionality can be extended to the automatic reconnect, can't it? Presently we require to provide a static list of IPs to be used at a reconnect time. By having a partition map of all the nodes, the thin client should be able to automate this piece.
-- Denis On Mon, Jun 18, 2018 at 6:12 AM Igor Sapego <isap...@apache.org> wrote: > I've created an IEP: [1] > > [1] - > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > Best Regards, > Igor > > > On Thu, Jun 14, 2018 at 4:17 PM Pavel Tupitsyn <ptupit...@apache.org> > wrote: > > > Ok, I see, this is what I was trying to understand, and this is an > > important note I think: > > > > * We should request AffinityFunction for each particular cache and only > > enable this functionality for known functions > > * Make sure that known server-side functions never change their behavior > > > > Thanks > > > > On Thu, Jun 14, 2018 at 3:39 PM, Igor Sapego <isap...@apache.org> wrote: > > > > > Vladimir is right, > > > > > > As far as I know, most users use affinity functions provided by Ignite. > > > So we could optimize for the default case and, in future, optionally, > > > let user implement their own AffinityFunction for thin clients. > > > > > > Best Regards, > > > Igor > > > > > > > > > On Thu, Jun 14, 2018 at 3:06 PM Vladimir Ozerov <voze...@gridgain.com> > > > wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
