Best Effort Affinity for thin clients

[Igor Sapego-2]

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

[Pavel Tupitsyn]

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 <[hidden email]> 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
>

[dmagda]

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 <[hidden email]>
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 <[hidden email]> 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
> >
>

[Igor Sapego]

Denis, that's right.

Best Regards,
Igor


On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
> > >
> >
>

[Pavel Tupitsyn]

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 <[hidden email]> wrote:

> Denis, that's right.
>
> Best Regards,
> Igor
>
>
> On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> 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
> > > >
> > >
> >
>

[Vladimir Ozerov]

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 <[hidden email]>
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 <[hidden email]>
> wrote:
>
> > Denis, that's right.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]>
> > 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
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]>
> > wrote:
> >
> > > Denis, that's right.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <[hidden email]>
> 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 <
> [hidden email]>
> > > > 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 <[hidden email]>
> > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > wrote:
> > >
> > > > Denis, that's right.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <[hidden email]>
> > 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 <
> > [hidden email]>
> > > > > 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 <[hidden email]
> >
> > > > 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]
> >
> > > 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 <[hidden email]>
> > > > wrote:
> > > >
> > > > > Denis, that's right.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <[hidden email]>
> > > 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 <
> > > [hidden email]>
> > > > > > 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 <
> [hidden email]
> > >
> > > > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[dmagda]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <
> [hidden email]
> > >
> > > > 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 <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Denis, that's right.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > > > On Wed, Jun 13, 2018 at 10:58 PM Denis Magda <[hidden email]>
> > > > 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 <
> > > > [hidden email]>
> > > > > > > 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 <
> > [hidden email]
> > > >
> > > > > > 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[dsetrakyan]

On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]> wrote:

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

Not sure if static IP list can be avoided. What Igor is suggesting is that
we try to pick the best node out of the static IP  list.

D.

[Vladimir Ozerov]

Denis,

Yes, in principle we can extend it. We are going to implement it in
subsequent phases of this IEP.

On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]> wrote:
>
> > 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.
> >
>
> Not sure if static IP list can be avoided. What Igor is suggesting is that
> we try to pick the best node out of the static IP  list.
>
> D.
>

[Igor Sapego-2]

Hello guys,

I've updated IEP page [1] describing proposed solution in more details and
proposing some changes for a protocol.

Please, take a look and let me know what you think.

[1] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients

Best Regards,
Igor


On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <[hidden email]>
wrote:

> Denis,
>
> Yes, in principle we can extend it. We are going to implement it in
> subsequent phases of this IEP.
>
> On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]> wrote:
> >
> > > 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.
> > >
> >
> > Not sure if static IP list can be avoided. What Igor is suggesting is
> that
> > we try to pick the best node out of the static IP  list.
> >
> > D.
> >
>

[Pavel Tupitsyn]

Hi Igor,

Looks good to me in general, except changing the response message format so
much.

Can we use a separate message to retrieve affinity topology version?
Set a flag as you describe, but don't put the version data into standard
response?

Just to keep the protocol cleaner, follow SRP to some extent, and keep
client implementations simpler
(especially for clients that ignore this flag).

Thoughts?

On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego <[hidden email]> wrote:

> Hello guys,
>
> I've updated IEP page [1] describing proposed solution in more details and
> proposing some changes for a protocol.
>
> Please, take a look and let me know what you think.
>
> [1] -
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>
> Best Regards,
> Igor
>
>
> On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Denis,
> >
> > Yes, in principle we can extend it. We are going to implement it in
> > subsequent phases of this IEP.
> >
> > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> [hidden email]>
> > wrote:
> >
> > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]>
> wrote:
> > >
> > > > 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.
> > > >
> > >
> > > Not sure if static IP list can be avoided. What Igor is suggesting is
> > that
> > > we try to pick the best node out of the static IP  list.
> > >
> > > D.
> > >
> >
>

[Vladimir Ozerov]

Igor,

I think that "Cache Partitions Request" should contain affinity topology
version. Otherwise we do not know what distribution is returned - the one
we expected, or some newer one. The latter may happen in case topology
changed or late affinity assignment happened between server response and
subsequent client partitions request.

Vladimir.

On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego <[hidden email]> wrote:

> Hello guys,
>
> I've updated IEP page [1] describing proposed solution in more details and
> proposing some changes for a protocol.
>
> Please, take a look and let me know what you think.
>
> [1] -
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>
> Best Regards,
> Igor
>
>
> On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Denis,
> >
> > Yes, in principle we can extend it. We are going to implement it in
> > subsequent phases of this IEP.
> >
> > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> [hidden email]>
> > wrote:
> >
> > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]>
> wrote:
> > >
> > > > 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.
> > > >
> > >
> > > Not sure if static IP list can be avoided. What Igor is suggesting is
> > that
> > > we try to pick the best node out of the static IP  list.
> > >
> > > D.
> > >
> >
>

[Igor Sapego-2]

Pavel,

This will require from client to send this new request periodically, I'm not
sure this will make clients simpler. Anyway, let's discuss it.

Vladimir,

With current proposal, we will have affinity info in message header.

Best Regards,
Igor


On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov <[hidden email]>
wrote:

> Igor,
>
> I think that "Cache Partitions Request" should contain affinity topology
> version. Otherwise we do not know what distribution is returned - the one
> we expected, or some newer one. The latter may happen in case topology
> changed or late affinity assignment happened between server response and
> subsequent client partitions request.
>
> Vladimir.
>
> On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego <[hidden email]> wrote:
>
> > Hello guys,
> >
> > I've updated IEP page [1] describing proposed solution in more details
> and
> > proposing some changes for a protocol.
> >
> > Please, take a look and let me know what you think.
> >
> > [1] -
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Denis,
> > >
> > > Yes, in principle we can extend it. We are going to implement it in
> > > subsequent phases of this IEP.
> > >
> > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> > [hidden email]>
> > > wrote:
> > >
> > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]>
> > wrote:
> > > >
> > > > > 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.
> > > > >
> > > >
> > > > Not sure if static IP list can be avoided. What Igor is suggesting is
> > > that
> > > > we try to pick the best node out of the static IP  list.
> > > >
> > > > D.
> > > >
> > >
> >
>

[Pavel Tupitsyn]

Igor,

>  It is proposed to add flag to every response, that shows whether the
Affinity Topology Version of the cluster has changed since the last request
from the client.
I propose to keep this flag. So no need for periodic checks. Makes sense?

On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego <[hidden email]> wrote:

> Pavel,
>
> This will require from client to send this new request periodically, I'm
> not
> sure this will make clients simpler. Anyway, let's discuss it.
>
> Vladimir,
>
> With current proposal, we will have affinity info in message header.
>
> Best Regards,
> Igor
>
>
> On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igor,
> >
> > I think that "Cache Partitions Request" should contain affinity topology
> > version. Otherwise we do not know what distribution is returned - the one
> > we expected, or some newer one. The latter may happen in case topology
> > changed or late affinity assignment happened between server response and
> > subsequent client partitions request.
> >
> > Vladimir.
> >
> > On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego <[hidden email]> wrote:
> >
> > > Hello guys,
> > >
> > > I've updated IEP page [1] describing proposed solution in more details
> > and
> > > proposing some changes for a protocol.
> > >
> > > Please, take a look and let me know what you think.
> > >
> > > [1] -
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <[hidden email]
> >
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Yes, in principle we can extend it. We are going to implement it in
> > > > subsequent phases of this IEP.
> > > >
> > > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> > > [hidden email]>
> > > > wrote:
> > > >
> > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]>
> > > wrote:
> > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > > Not sure if static IP list can be avoided. What Igor is suggesting
> is
> > > > that
> > > > > we try to pick the best node out of the static IP  list.
> > > > >
> > > > > D.
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

Pavel,

Yeah, it makes sense, but to me it seems that this approach can lead
to more complicated client logic, as it will require to make additional call
to every server, that reports affinity topology change.

Guys, WDYT?

Best Regards,
Igor


On Tue, Jan 15, 2019 at 10:59 PM Pavel Tupitsyn <[hidden email]>
wrote:

> Igor,
>
> >  It is proposed to add flag to every response, that shows whether the
> Affinity Topology Version of the cluster has changed since the last request
> from the client.
> I propose to keep this flag. So no need for periodic checks. Makes sense?
>
> On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego <[hidden email]> wrote:
>
> > Pavel,
> >
> > This will require from client to send this new request periodically, I'm
> > not
> > sure this will make clients simpler. Anyway, let's discuss it.
> >
> > Vladimir,
> >
> > With current proposal, we will have affinity info in message header.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Igor,
> > >
> > > I think that "Cache Partitions Request" should contain affinity
> topology
> > > version. Otherwise we do not know what distribution is returned - the
> one
> > > we expected, or some newer one. The latter may happen in case topology
> > > changed or late affinity assignment happened between server response
> and
> > > subsequent client partitions request.
> > >
> > > Vladimir.
> > >
> > > On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego <[hidden email]>
> wrote:
> > >
> > > > Hello guys,
> > > >
> > > > I've updated IEP page [1] describing proposed solution in more
> details
> > > and
> > > > proposing some changes for a protocol.
> > > >
> > > > Please, take a look and let me know what you think.
> > > >
> > > > [1] -
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > Yes, in principle we can extend it. We are going to implement it in
> > > > > subsequent phases of this IEP.
> > > > >
> > > > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> > > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <[hidden email]
> >
> > > > wrote:
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > Not sure if static IP list can be avoided. What Igor is
> suggesting
> > is
> > > > > that
> > > > > > we try to pick the best node out of the static IP  list.
> > > > > >
> > > > > > D.
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

>  to every server
I did not think of this issue. Now I agree with your approach.
Can you please add an explanation of this to the IEP?

Thanks!

On Wed, Jan 16, 2019 at 2:53 PM Igor Sapego <[hidden email]> wrote:

> Pavel,
>
> Yeah, it makes sense, but to me it seems that this approach can lead
> to more complicated client logic, as it will require to make additional
> call
> to every server, that reports affinity topology change.
>
> Guys, WDYT?
>
> Best Regards,
> Igor
>
>
> On Tue, Jan 15, 2019 at 10:59 PM Pavel Tupitsyn <[hidden email]>
> wrote:
>
> > Igor,
> >
> > >  It is proposed to add flag to every response, that shows whether the
> > Affinity Topology Version of the cluster has changed since the last
> request
> > from the client.
> > I propose to keep this flag. So no need for periodic checks. Makes sense?
> >
> > On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego <[hidden email]> wrote:
> >
> > > Pavel,
> > >
> > > This will require from client to send this new request periodically,
> I'm
> > > not
> > > sure this will make clients simpler. Anyway, let's discuss it.
> > >
> > > Vladimir,
> > >
> > > With current proposal, we will have affinity info in message header.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov <[hidden email]
> >
> > > wrote:
> > >
> > > > Igor,
> > > >
> > > > I think that "Cache Partitions Request" should contain affinity
> > topology
> > > > version. Otherwise we do not know what distribution is returned - the
> > one
> > > > we expected, or some newer one. The latter may happen in case
> topology
> > > > changed or late affinity assignment happened between server response
> > and
> > > > subsequent client partitions request.
> > > >
> > > > Vladimir.
> > > >
> > > > On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego <[hidden email]>
> > wrote:
> > > >
> > > > > Hello guys,
> > > > >
> > > > > I've updated IEP page [1] describing proposed solution in more
> > details
> > > > and
> > > > > proposing some changes for a protocol.
> > > > >
> > > > > Please, take a look and let me know what you think.
> > > > >
> > > > > [1] -
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <
> > [hidden email]
> > > >
> > > > > wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > Yes, in principle we can extend it. We are going to implement it
> in
> > > > > > subsequent phases of this IEP.
> > > > > >
> > > > > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> > > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <
> [hidden email]
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > >
> > > > > > > Not sure if static IP list can be avoided. What Igor is
> > suggesting
> > > is
> > > > > > that
> > > > > > > we try to pick the best node out of the static IP  list.
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

Yeah, I'll add it.

Best Regards,
Igor


On Wed, Jan 16, 2019 at 11:08 PM Pavel Tupitsyn <[hidden email]>
wrote:

> >  to every server
> I did not think of this issue. Now I agree with your approach.
> Can you please add an explanation of this to the IEP?
>
> Thanks!
>
> On Wed, Jan 16, 2019 at 2:53 PM Igor Sapego <[hidden email]> wrote:
>
> > Pavel,
> >
> > Yeah, it makes sense, but to me it seems that this approach can lead
> > to more complicated client logic, as it will require to make additional
> > call
> > to every server, that reports affinity topology change.
> >
> > Guys, WDYT?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Jan 15, 2019 at 10:59 PM Pavel Tupitsyn <[hidden email]>
> > wrote:
> >
> > > Igor,
> > >
> > > >  It is proposed to add flag to every response, that shows whether the
> > > Affinity Topology Version of the cluster has changed since the last
> > request
> > > from the client.
> > > I propose to keep this flag. So no need for periodic checks. Makes
> sense?
> > >
> > > On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego <[hidden email]>
> wrote:
> > >
> > > > Pavel,
> > > >
> > > > This will require from client to send this new request periodically,
> > I'm
> > > > not
> > > > sure this will make clients simpler. Anyway, let's discuss it.
> > > >
> > > > Vladimir,
> > > >
> > > > With current proposal, we will have affinity info in message header.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > Igor,
> > > > >
> > > > > I think that "Cache Partitions Request" should contain affinity
> > > topology
> > > > > version. Otherwise we do not know what distribution is returned -
> the
> > > one
> > > > > we expected, or some newer one. The latter may happen in case
> > topology
> > > > > changed or late affinity assignment happened between server
> response
> > > and
> > > > > subsequent client partitions request.
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > > >
> > > > > > Hello guys,
> > > > > >
> > > > > > I've updated IEP page [1] describing proposed solution in more
> > > details
> > > > > and
> > > > > > proposing some changes for a protocol.
> > > > > >
> > > > > > Please, take a look and let me know what you think.
> > > > > >
> > > > > > [1] -
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov <
> > > [hidden email]
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > Yes, in principle we can extend it. We are going to implement
> it
> > in
> > > > > > > subsequent phases of this IEP.
> > > > > > >
> > > > > > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> > > > > > [hidden email]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <
> > [hidden email]
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Not sure if static IP list can be avoided. What Igor is
> > > suggesting
> > > > is
> > > > > > > that
> > > > > > > > we try to pick the best node out of the static IP  list.
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>