Best Effort Affinity for thin clients

[Igor Sapego-2]

Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <[hidden email]> wrote:

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

[Pavel Tupitsyn]

Igor, I have a feeling that we should omit Cache Group stuff from the
protocol.
It is a rare use case and even then dealing with them on client barely
saves some memory.

We can keep it simple and have partition map per cacheId. Thoughts?

On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]> wrote:

> Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <[hidden email]> wrote:
>
> > 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.
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

[Vladimir Ozerov]

Pavel, Igor,

This is not very accurate to say that this will not save memory. In
practice we observed a number of OOME issues on the server-side due to many
caches and it was one of motivations for cache groups (another one disk
access optimizations). On the other hand, I agree that we'd better to avoid
cache groups in the protocol because this is internal implementation detail
which is likely (I hope so) to be changed in future.

So I have another proposal - let's track caches with the same affinity
distribution instead. That is, normally most of PARTITIONED caches will
have very few variants of configuration: it will be Rendezvous affinity
function, most likely with default partition number and with 1-2 backups at
most. So when affinity distribution for specific cache is requested, we can
append to the response *list of caches with the same distribution*. I.e.:

class AffinityResponse {
    Object distribution;    // Actual distribution
    List<Integer> cacheIds; // Caches with similar distribution
}

Makes sense?

On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <[hidden email]> wrote:

> Igor, I have a feeling that we should omit Cache Group stuff from the
> protocol.
> It is a rare use case and even then dealing with them on client barely
> saves some memory.
>
> We can keep it simple and have partition map per cacheId. Thoughts?
>
> On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]> wrote:
>
> > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <[hidden email]> wrote:
> >
> > > 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.
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

[Igor Sapego-2]

Guys,

Can you explain why do we want to avoid Cache groups in protocol?

If it's about simplicity of the protocol, then removing cache groups will
not help much with it - we will still need to include "knownCacheIds"
field in request and "cachesWithTheSamePartitioning" field in response.
And also, since when do Ignite prefers simplicity over performance?

If it's about not wanting to show internals of Ignite then it sounds like
a very weak argument to me, since Cache Groups is a public thing [1].

[1] - https://apacheignite.readme.io/docs/cache-groups

Best Regards,
Igor


On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <[hidden email]>
wrote:

> Pavel, Igor,
>
> This is not very accurate to say that this will not save memory. In
> practice we observed a number of OOME issues on the server-side due to many
> caches and it was one of motivations for cache groups (another one disk
> access optimizations). On the other hand, I agree that we'd better to avoid
> cache groups in the protocol because this is internal implementation detail
> which is likely (I hope so) to be changed in future.
>
> So I have another proposal - let's track caches with the same affinity
> distribution instead. That is, normally most of PARTITIONED caches will
> have very few variants of configuration: it will be Rendezvous affinity
> function, most likely with default partition number and with 1-2 backups at
> most. So when affinity distribution for specific cache is requested, we can
> append to the response *list of caches with the same distribution*. I.e.:
>
> class AffinityResponse {
>     Object distribution;    // Actual distribution
>     List<Integer> cacheIds; // Caches with similar distribution
> }
>
> Makes sense?
>
> On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <[hidden email]>
> wrote:
>
> > Igor, I have a feeling that we should omit Cache Group stuff from the
> > protocol.
> > It is a rare use case and even then dealing with them on client barely
> > saves some memory.
> >
> > We can keep it simple and have partition map per cacheId. Thoughts?
> >
> > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]> wrote:
> >
> > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <[hidden email]>
> wrote:
> > >
> > > > 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.
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

[Vladimir Ozerov]

Igor,

Yes, cache groups are public API. However, we try to avoid new APIs
depending on them.
The main point from my side is that “similar cache group” can be easily
generalized to “similar distribution”. This way we avoid cache groups on
protocol level at virtually no cost.

Vladimir.

пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:

> Guys,
>
> Can you explain why do we want to avoid Cache groups in protocol?
>
> If it's about simplicity of the protocol, then removing cache groups will
> not help much with it - we will still need to include "knownCacheIds"
> field in request and "cachesWithTheSamePartitioning" field in response.
> And also, since when do Ignite prefers simplicity over performance?
>
> If it's about not wanting to show internals of Ignite then it sounds like
> a very weak argument to me, since Cache Groups is a public thing [1].
>
> [1] - https://apacheignite.readme.io/docs/cache-groups
>
> Best Regards,
> Igor
>
>
> On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Pavel, Igor,
> >
> > This is not very accurate to say that this will not save memory. In
> > practice we observed a number of OOME issues on the server-side due to
> many
> > caches and it was one of motivations for cache groups (another one disk
> > access optimizations). On the other hand, I agree that we'd better to
> avoid
> > cache groups in the protocol because this is internal implementation
> detail
> > which is likely (I hope so) to be changed in future.
> >
> > So I have another proposal - let's track caches with the same affinity
> > distribution instead. That is, normally most of PARTITIONED caches will
> > have very few variants of configuration: it will be Rendezvous affinity
> > function, most likely with default partition number and with 1-2 backups
> at
> > most. So when affinity distribution for specific cache is requested, we
> can
> > append to the response *list of caches with the same distribution*. I.e.:
> >
> > class AffinityResponse {
> >     Object distribution;    // Actual distribution
> >     List<Integer> cacheIds; // Caches with similar distribution
> > }
> >
> > Makes sense?
> >
> > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <[hidden email]>
> > wrote:
> >
> > > Igor, I have a feeling that we should omit Cache Group stuff from the
> > > protocol.
> > > It is a rare use case and even then dealing with them on client barely
> > > saves some memory.
> > >
> > > We can keep it simple and have partition map per cacheId. Thoughts?
> > >
> > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]> wrote:
> > >
> > > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <[hidden email]>
> > wrote:
> > > >
> > > > > 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.
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

Vladimir,

So correct me if I'm wrong, what you propose is to avoid mentioning
of cache groups, and use instead of "cache group" term something like
"distribution"? Or do you propose some changes in protocol? If so, can
you briefly explain, what kind of changes they are?

Best Regards,
Igor


On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <[hidden email]> wrote:

> Igor,
>
> Yes, cache groups are public API. However, we try to avoid new APIs
> depending on them.
> The main point from my side is that “similar cache group” can be easily
> generalized to “similar distribution”. This way we avoid cache groups on
> protocol level at virtually no cost.
>
> Vladimir.
>
> пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:
>
> > Guys,
> >
> > Can you explain why do we want to avoid Cache groups in protocol?
> >
> > If it's about simplicity of the protocol, then removing cache groups will
> > not help much with it - we will still need to include "knownCacheIds"
> > field in request and "cachesWithTheSamePartitioning" field in response.
> > And also, since when do Ignite prefers simplicity over performance?
> >
> > If it's about not wanting to show internals of Ignite then it sounds like
> > a very weak argument to me, since Cache Groups is a public thing [1].
> >
> > [1] - https://apacheignite.readme.io/docs/cache-groups
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Pavel, Igor,
> > >
> > > This is not very accurate to say that this will not save memory. In
> > > practice we observed a number of OOME issues on the server-side due to
> > many
> > > caches and it was one of motivations for cache groups (another one disk
> > > access optimizations). On the other hand, I agree that we'd better to
> > avoid
> > > cache groups in the protocol because this is internal implementation
> > detail
> > > which is likely (I hope so) to be changed in future.
> > >
> > > So I have another proposal - let's track caches with the same affinity
> > > distribution instead. That is, normally most of PARTITIONED caches will
> > > have very few variants of configuration: it will be Rendezvous affinity
> > > function, most likely with default partition number and with 1-2
> backups
> > at
> > > most. So when affinity distribution for specific cache is requested, we
> > can
> > > append to the response *list of caches with the same distribution*.
> I.e.:
> > >
> > > class AffinityResponse {
> > >     Object distribution;    // Actual distribution
> > >     List<Integer> cacheIds; // Caches with similar distribution
> > > }
> > >
> > > Makes sense?
> > >
> > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <[hidden email]>
> > > wrote:
> > >
> > > > Igor, I have a feeling that we should omit Cache Group stuff from the
> > > > protocol.
> > > > It is a rare use case and even then dealing with them on client
> barely
> > > > saves some memory.
> > > >
> > > > We can keep it simple and have partition map per cacheId. Thoughts?
> > > >
> > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]>
> wrote:
> > > >
> > > > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > > >
> > > > > > 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.
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Vladimir Ozerov]

Igor,

My idea is simply to add the list of caches with the same distribution to
the end of partition response. Client can use this information to populate
partition info for more caches in a single request.

On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]> wrote:

> Vladimir,
>
> So correct me if I'm wrong, what you propose is to avoid mentioning
> of cache groups, and use instead of "cache group" term something like
> "distribution"? Or do you propose some changes in protocol? If so, can
> you briefly explain, what kind of changes they are?
>
> Best Regards,
> Igor
>
>
> On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igor,
> >
> > Yes, cache groups are public API. However, we try to avoid new APIs
> > depending on them.
> > The main point from my side is that “similar cache group” can be easily
> > generalized to “similar distribution”. This way we avoid cache groups on
> > protocol level at virtually no cost.
> >
> > Vladimir.
> >
> > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:
> >
> > > Guys,
> > >
> > > Can you explain why do we want to avoid Cache groups in protocol?
> > >
> > > If it's about simplicity of the protocol, then removing cache groups
> will
> > > not help much with it - we will still need to include "knownCacheIds"
> > > field in request and "cachesWithTheSamePartitioning" field in response.
> > > And also, since when do Ignite prefers simplicity over performance?
> > >
> > > If it's about not wanting to show internals of Ignite then it sounds
> like
> > > a very weak argument to me, since Cache Groups is a public thing [1].
> > >
> > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <[hidden email]>
> > > wrote:
> > >
> > > > Pavel, Igor,
> > > >
> > > > This is not very accurate to say that this will not save memory. In
> > > > practice we observed a number of OOME issues on the server-side due
> to
> > > many
> > > > caches and it was one of motivations for cache groups (another one
> disk
> > > > access optimizations). On the other hand, I agree that we'd better to
> > > avoid
> > > > cache groups in the protocol because this is internal implementation
> > > detail
> > > > which is likely (I hope so) to be changed in future.
> > > >
> > > > So I have another proposal - let's track caches with the same
> affinity
> > > > distribution instead. That is, normally most of PARTITIONED caches
> will
> > > > have very few variants of configuration: it will be Rendezvous
> affinity
> > > > function, most likely with default partition number and with 1-2
> > backups
> > > at
> > > > most. So when affinity distribution for specific cache is requested,
> we
> > > can
> > > > append to the response *list of caches with the same distribution*.
> > I.e.:
> > > >
> > > > class AffinityResponse {
> > > >     Object distribution;    // Actual distribution
> > > >     List<Integer> cacheIds; // Caches with similar distribution
> > > > }
> > > >
> > > > Makes sense?
> > > >
> > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <[hidden email]>
> > > > wrote:
> > > >
> > > > > Igor, I have a feeling that we should omit Cache Group stuff from
> the
> > > > > protocol.
> > > > > It is a rare use case and even then dealing with them on client
> > barely
> > > > > saves some memory.
> > > > >
> > > > > We can keep it simple and have partition map per cacheId. Thoughts?
> > > > >
> > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]>
> > wrote:
> > > > >
> > > > > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <[hidden email]>
> > > > wrote:
> > > > > >
> > > > > > > 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.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

Ok, I understand now. I'll try updating IEP according to this proposal and
notify you guys.

Best Regards,
Igor


On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <[hidden email]> wrote:

> Igor,
>
> My idea is simply to add the list of caches with the same distribution to
> the end of partition response. Client can use this information to populate
> partition info for more caches in a single request.
>
> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]> wrote:
>
> > Vladimir,
> >
> > So correct me if I'm wrong, what you propose is to avoid mentioning
> > of cache groups, and use instead of "cache group" term something like
> > "distribution"? Or do you propose some changes in protocol? If so, can
> > you briefly explain, what kind of changes they are?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Igor,
> > >
> > > Yes, cache groups are public API. However, we try to avoid new APIs
> > > depending on them.
> > > The main point from my side is that “similar cache group” can be easily
> > > generalized to “similar distribution”. This way we avoid cache groups
> on
> > > protocol level at virtually no cost.
> > >
> > > Vladimir.
> > >
> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:
> > >
> > > > Guys,
> > > >
> > > > Can you explain why do we want to avoid Cache groups in protocol?
> > > >
> > > > If it's about simplicity of the protocol, then removing cache groups
> > will
> > > > not help much with it - we will still need to include "knownCacheIds"
> > > > field in request and "cachesWithTheSamePartitioning" field in
> response.
> > > > And also, since when do Ignite prefers simplicity over performance?
> > > >
> > > > If it's about not wanting to show internals of Ignite then it sounds
> > like
> > > > a very weak argument to me, since Cache Groups is a public thing [1].
> > > >
> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> [hidden email]>
> > > > wrote:
> > > >
> > > > > Pavel, Igor,
> > > > >
> > > > > This is not very accurate to say that this will not save memory. In
> > > > > practice we observed a number of OOME issues on the server-side due
> > to
> > > > many
> > > > > caches and it was one of motivations for cache groups (another one
> > disk
> > > > > access optimizations). On the other hand, I agree that we'd better
> to
> > > > avoid
> > > > > cache groups in the protocol because this is internal
> implementation
> > > > detail
> > > > > which is likely (I hope so) to be changed in future.
> > > > >
> > > > > So I have another proposal - let's track caches with the same
> > affinity
> > > > > distribution instead. That is, normally most of PARTITIONED caches
> > will
> > > > > have very few variants of configuration: it will be Rendezvous
> > affinity
> > > > > function, most likely with default partition number and with 1-2
> > > backups
> > > > at
> > > > > most. So when affinity distribution for specific cache is
> requested,
> > we
> > > > can
> > > > > append to the response *list of caches with the same distribution*.
> > > I.e.:
> > > > >
> > > > > class AffinityResponse {
> > > > >     Object distribution;    // Actual distribution
> > > > >     List<Integer> cacheIds; // Caches with similar distribution
> > > > > }
> > > > >
> > > > > Makes sense?
> > > > >
> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Igor, I have a feeling that we should omit Cache Group stuff from
> > the
> > > > > > protocol.
> > > > > > It is a rare use case and even then dealing with them on client
> > > barely
> > > > > > saves some memory.
> > > > > >
> > > > > > We can keep it simple and have partition map per cacheId.
> Thoughts?
> > > > > >
> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > > > >
> > > > > > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> [hidden email]>
> > > > > wrote:
> > > > > > >
> > > > > > > > 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.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

I've updated IEP page: [1]

What do you think now? To me it looks cleaner.

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

Best Regards,
Igor


On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]> wrote:

> Ok, I understand now. I'll try updating IEP according to this proposal and
> notify you guys.
>
> Best Regards,
> Igor
>
>
> On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <[hidden email]>
> wrote:
>
>> Igor,
>>
>> My idea is simply to add the list of caches with the same distribution to
>> the end of partition response. Client can use this information to populate
>> partition info for more caches in a single request.
>>
>> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]> wrote:
>>
>> > Vladimir,
>> >
>> > So correct me if I'm wrong, what you propose is to avoid mentioning
>> > of cache groups, and use instead of "cache group" term something like
>> > "distribution"? Or do you propose some changes in protocol? If so, can
>> > you briefly explain, what kind of changes they are?
>> >
>> > Best Regards,
>> > Igor
>> >
>> >
>> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <[hidden email]>
>> > wrote:
>> >
>> > > Igor,
>> > >
>> > > Yes, cache groups are public API. However, we try to avoid new APIs
>> > > depending on them.
>> > > The main point from my side is that “similar cache group” can be
>> easily
>> > > generalized to “similar distribution”. This way we avoid cache groups
>> on
>> > > protocol level at virtually no cost.
>> > >
>> > > Vladimir.
>> > >
>> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:
>> > >
>> > > > Guys,
>> > > >
>> > > > Can you explain why do we want to avoid Cache groups in protocol?
>> > > >
>> > > > If it's about simplicity of the protocol, then removing cache groups
>> > will
>> > > > not help much with it - we will still need to include
>> "knownCacheIds"
>> > > > field in request and "cachesWithTheSamePartitioning" field in
>> response.
>> > > > And also, since when do Ignite prefers simplicity over performance?
>> > > >
>> > > > If it's about not wanting to show internals of Ignite then it sounds
>> > like
>> > > > a very weak argument to me, since Cache Groups is a public thing
>> [1].
>> > > >
>> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
>> > > >
>> > > > Best Regards,
>> > > > Igor
>> > > >
>> > > >
>> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
>> [hidden email]>
>> > > > wrote:
>> > > >
>> > > > > Pavel, Igor,
>> > > > >
>> > > > > This is not very accurate to say that this will not save memory.
>> In
>> > > > > practice we observed a number of OOME issues on the server-side
>> due
>> > to
>> > > > many
>> > > > > caches and it was one of motivations for cache groups (another one
>> > disk
>> > > > > access optimizations). On the other hand, I agree that we'd
>> better to
>> > > > avoid
>> > > > > cache groups in the protocol because this is internal
>> implementation
>> > > > detail
>> > > > > which is likely (I hope so) to be changed in future.
>> > > > >
>> > > > > So I have another proposal - let's track caches with the same
>> > affinity
>> > > > > distribution instead. That is, normally most of PARTITIONED caches
>> > will
>> > > > > have very few variants of configuration: it will be Rendezvous
>> > affinity
>> > > > > function, most likely with default partition number and with 1-2
>> > > backups
>> > > > at
>> > > > > most. So when affinity distribution for specific cache is
>> requested,
>> > we
>> > > > can
>> > > > > append to the response *list of caches with the same
>> distribution*.
>> > > I.e.:
>> > > > >
>> > > > > class AffinityResponse {
>> > > > >     Object distribution;    // Actual distribution
>> > > > >     List<Integer> cacheIds; // Caches with similar distribution
>> > > > > }
>> > > > >
>> > > > > Makes sense?
>> > > > >
>> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
>> [hidden email]>
>> > > > > wrote:
>> > > > >
>> > > > > > Igor, I have a feeling that we should omit Cache Group stuff
>> from
>> > the
>> > > > > > protocol.
>> > > > > > It is a rare use case and even then dealing with them on client
>> > > barely
>> > > > > > saves some memory.
>> > > > > >
>> > > > > > We can keep it simple and have partition map per cacheId.
>> Thoughts?
>> > > > > >
>> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <[hidden email]>
>> > > wrote:
>> > > > > >
>> > > > > > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
>> [hidden email]>
>> > > > > wrote:
>> > > > > > >
>> > > > > > > > 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.
>> > > > > > > >> > > > > > > >
>> > > > > > > >> > > > > > >
>> > > > > > > >> > > > > >
>> > > > > > > >> > > > >
>> > > > > > > >> > > >
>> > > > > > > >> > >
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

[Pavel Tupitsyn]

Looks good to me.

On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]> wrote:

> I've updated IEP page: [1]
>
> What do you think now? To me it looks cleaner.
>
> [1] -
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>
> Best Regards,
> Igor
>
>
> On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]> wrote:
>
> > Ok, I understand now. I'll try updating IEP according to this proposal
> and
> > notify you guys.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> >> Igor,
> >>
> >> My idea is simply to add the list of caches with the same distribution
> to
> >> the end of partition response. Client can use this information to
> populate
> >> partition info for more caches in a single request.
> >>
> >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]> wrote:
> >>
> >> > Vladimir,
> >> >
> >> > So correct me if I'm wrong, what you propose is to avoid mentioning
> >> > of cache groups, and use instead of "cache group" term something like
> >> > "distribution"? Or do you propose some changes in protocol? If so, can
> >> > you briefly explain, what kind of changes they are?
> >> >
> >> > Best Regards,
> >> > Igor
> >> >
> >> >
> >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <[hidden email]>
> >> > wrote:
> >> >
> >> > > Igor,
> >> > >
> >> > > Yes, cache groups are public API. However, we try to avoid new APIs
> >> > > depending on them.
> >> > > The main point from my side is that “similar cache group” can be
> >> easily
> >> > > generalized to “similar distribution”. This way we avoid cache
> groups
> >> on
> >> > > protocol level at virtually no cost.
> >> > >
> >> > > Vladimir.
> >> > >
> >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:
> >> > >
> >> > > > Guys,
> >> > > >
> >> > > > Can you explain why do we want to avoid Cache groups in protocol?
> >> > > >
> >> > > > If it's about simplicity of the protocol, then removing cache
> groups
> >> > will
> >> > > > not help much with it - we will still need to include
> >> "knownCacheIds"
> >> > > > field in request and "cachesWithTheSamePartitioning" field in
> >> response.
> >> > > > And also, since when do Ignite prefers simplicity over
> performance?
> >> > > >
> >> > > > If it's about not wanting to show internals of Ignite then it
> sounds
> >> > like
> >> > > > a very weak argument to me, since Cache Groups is a public thing
> >> [1].
> >> > > >
> >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> >> > > >
> >> > > > Best Regards,
> >> > > > Igor
> >> > > >
> >> > > >
> >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> >> [hidden email]>
> >> > > > wrote:
> >> > > >
> >> > > > > Pavel, Igor,
> >> > > > >
> >> > > > > This is not very accurate to say that this will not save memory.
> >> In
> >> > > > > practice we observed a number of OOME issues on the server-side
> >> due
> >> > to
> >> > > > many
> >> > > > > caches and it was one of motivations for cache groups (another
> one
> >> > disk
> >> > > > > access optimizations). On the other hand, I agree that we'd
> >> better to
> >> > > > avoid
> >> > > > > cache groups in the protocol because this is internal
> >> implementation
> >> > > > detail
> >> > > > > which is likely (I hope so) to be changed in future.
> >> > > > >
> >> > > > > So I have another proposal - let's track caches with the same
> >> > affinity
> >> > > > > distribution instead. That is, normally most of PARTITIONED
> caches
> >> > will
> >> > > > > have very few variants of configuration: it will be Rendezvous
> >> > affinity
> >> > > > > function, most likely with default partition number and with 1-2
> >> > > backups
> >> > > > at
> >> > > > > most. So when affinity distribution for specific cache is
> >> requested,
> >> > we
> >> > > > can
> >> > > > > append to the response *list of caches with the same
> >> distribution*.
> >> > > I.e.:
> >> > > > >
> >> > > > > class AffinityResponse {
> >> > > > >     Object distribution;    // Actual distribution
> >> > > > >     List<Integer> cacheIds; // Caches with similar distribution
> >> > > > > }
> >> > > > >
> >> > > > > Makes sense?
> >> > > > >
> >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> >> [hidden email]>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Igor, I have a feeling that we should omit Cache Group stuff
> >> from
> >> > the
> >> > > > > > protocol.
> >> > > > > > It is a rare use case and even then dealing with them on
> client
> >> > > barely
> >> > > > > > saves some memory.
> >> > > > > >
> >> > > > > > We can keep it simple and have partition map per cacheId.
> >> Thoughts?
> >> > > > > >
> >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> [hidden email]>
> >> > > wrote:
> >> > > > > >
> >> > > > > > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> >> [hidden email]>
> >> > > > > wrote:
> >> > > > > > >
> >> > > > > > > > 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.
> >> > > > > > > >> > > > > > > >
> >> > > > > > > >> > > > > > >
> >> > > > > > > >> > > > > >
> >> > > > > > > >> > > > >
> >> > > > > > > >> > > >
> >> > > > > > > >> > >
> >> > > > > > > >> >
> >> > > > > > > >>
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

[Igor Sapego-2]

Guys, I've updated the IEP page [1] once again.

Please, pay attention to sections Cache affinity mapping acquiring
(4.a, format of Cache Partitions Request) and Changes to cache
operations with single key (3 and 4, algorithm).

Long story short, I've decided to add some additional data to Cache
Partitions Response, so that client can determine how to calculate
partition for a given key properly.

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

Best Regards,
Igor


On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <[hidden email]> wrote:

> Looks good to me.
>
> On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]> wrote:
>
> > I've updated IEP page: [1]
> >
> > What do you think now? To me it looks cleaner.
> >
> > [1] -
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]> wrote:
> >
> > > Ok, I understand now. I'll try updating IEP according to this proposal
> > and
> > > notify you guys.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <[hidden email]>
> > > wrote:
> > >
> > >> Igor,
> > >>
> > >> My idea is simply to add the list of caches with the same distribution
> > to
> > >> the end of partition response. Client can use this information to
> > populate
> > >> partition info for more caches in a single request.
> > >>
> > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]>
> wrote:
> > >>
> > >> > Vladimir,
> > >> >
> > >> > So correct me if I'm wrong, what you propose is to avoid mentioning
> > >> > of cache groups, and use instead of "cache group" term something
> like
> > >> > "distribution"? Or do you propose some changes in protocol? If so,
> can
> > >> > you briefly explain, what kind of changes they are?
> > >> >
> > >> > Best Regards,
> > >> > Igor
> > >> >
> > >> >
> > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> [hidden email]>
> > >> > wrote:
> > >> >
> > >> > > Igor,
> > >> > >
> > >> > > Yes, cache groups are public API. However, we try to avoid new
> APIs
> > >> > > depending on them.
> > >> > > The main point from my side is that “similar cache group” can be
> > >> easily
> > >> > > generalized to “similar distribution”. This way we avoid cache
> > groups
> > >> on
> > >> > > protocol level at virtually no cost.
> > >> > >
> > >> > > Vladimir.
> > >> > >
> > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:
> > >> > >
> > >> > > > Guys,
> > >> > > >
> > >> > > > Can you explain why do we want to avoid Cache groups in
> protocol?
> > >> > > >
> > >> > > > If it's about simplicity of the protocol, then removing cache
> > groups
> > >> > will
> > >> > > > not help much with it - we will still need to include
> > >> "knownCacheIds"
> > >> > > > field in request and "cachesWithTheSamePartitioning" field in
> > >> response.
> > >> > > > And also, since when do Ignite prefers simplicity over
> > performance?
> > >> > > >
> > >> > > > If it's about not wanting to show internals of Ignite then it
> > sounds
> > >> > like
> > >> > > > a very weak argument to me, since Cache Groups is a public thing
> > >> [1].
> > >> > > >
> > >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > >> > > >
> > >> > > > Best Regards,
> > >> > > > Igor
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > >> [hidden email]>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Pavel, Igor,
> > >> > > > >
> > >> > > > > This is not very accurate to say that this will not save
> memory.
> > >> In
> > >> > > > > practice we observed a number of OOME issues on the
> server-side
> > >> due
> > >> > to
> > >> > > > many
> > >> > > > > caches and it was one of motivations for cache groups (another
> > one
> > >> > disk
> > >> > > > > access optimizations). On the other hand, I agree that we'd
> > >> better to
> > >> > > > avoid
> > >> > > > > cache groups in the protocol because this is internal
> > >> implementation
> > >> > > > detail
> > >> > > > > which is likely (I hope so) to be changed in future.
> > >> > > > >
> > >> > > > > So I have another proposal - let's track caches with the same
> > >> > affinity
> > >> > > > > distribution instead. That is, normally most of PARTITIONED
> > caches
> > >> > will
> > >> > > > > have very few variants of configuration: it will be Rendezvous
> > >> > affinity
> > >> > > > > function, most likely with default partition number and with
> 1-2
> > >> > > backups
> > >> > > > at
> > >> > > > > most. So when affinity distribution for specific cache is
> > >> requested,
> > >> > we
> > >> > > > can
> > >> > > > > append to the response *list of caches with the same
> > >> distribution*.
> > >> > > I.e.:
> > >> > > > >
> > >> > > > > class AffinityResponse {
> > >> > > > >     Object distribution;    // Actual distribution
> > >> > > > >     List<Integer> cacheIds; // Caches with similar
> distribution
> > >> > > > > }
> > >> > > > >
> > >> > > > > Makes sense?
> > >> > > > >
> > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> > >> [hidden email]>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > Igor, I have a feeling that we should omit Cache Group stuff
> > >> from
> > >> > the
> > >> > > > > > protocol.
> > >> > > > > > It is a rare use case and even then dealing with them on
> > client
> > >> > > barely
> > >> > > > > > saves some memory.
> > >> > > > > >
> > >> > > > > > We can keep it simple and have partition map per cacheId.
> > >> Thoughts?
> > >> > > > > >
> > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> > [hidden email]>
> > >> > > wrote:
> > >> > > > > >
> > >> > > > > > > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> > >> [hidden email]>
> > >> > > > > wrote:
> > >> > > > > > >
> > >> > > > > > > > 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.
> > >> > > > > > > >> > > > > > > >
> > >> > > > > > > >> > > > > > >
> > >> > > > > > > >> > > > > >
> > >> > > > > > > >> > > > >
> > >> > > > > > > >> > > >
> > >> > > > > > > >> > >
> > >> > > > > > > >> >
> > >> > > > > > > >>
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

[Pavel Tupitsyn]

Hi,

I'm in progress of implementing this IEP for Ignite.NET, and I have
concerns about the following:

> On thin client startup it connects to all nodes provided by client
configuration

Should we, at least, make this behavior optional?

One of the benefits of thin client is quick startup/connect time and low
resource usage.
Adding "connect all" behavior can negate those benefits, especially on
large clusters.

Thoughts?

On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]> wrote:

> Guys, I've updated the IEP page [1] once again.
>
> Please, pay attention to sections Cache affinity mapping acquiring
> (4.a, format of Cache Partitions Request) and Changes to cache
> operations with single key (3 and 4, algorithm).
>
> Long story short, I've decided to add some additional data to Cache
> Partitions Response, so that client can determine how to calculate
> partition for a given key properly.
>
> [1] -
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>
> Best Regards,
> Igor
>
>
> On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <[hidden email]>
> wrote:
>
> > Looks good to me.
> >
> > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]> wrote:
> >
> > > I've updated IEP page: [1]
> > >
> > > What do you think now? To me it looks cleaner.
> > >
> > > [1] -
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]> wrote:
> > >
> > > > Ok, I understand now. I'll try updating IEP according to this
> proposal
> > > and
> > > > notify you guys.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <[hidden email]
> >
> > > > wrote:
> > > >
> > > >> Igor,
> > > >>
> > > >> My idea is simply to add the list of caches with the same
> distribution
> > > to
> > > >> the end of partition response. Client can use this information to
> > > populate
> > > >> partition info for more caches in a single request.
> > > >>
> > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]>
> > wrote:
> > > >>
> > > >> > Vladimir,
> > > >> >
> > > >> > So correct me if I'm wrong, what you propose is to avoid
> mentioning
> > > >> > of cache groups, and use instead of "cache group" term something
> > like
> > > >> > "distribution"? Or do you propose some changes in protocol? If so,
> > can
> > > >> > you briefly explain, what kind of changes they are?
> > > >> >
> > > >> > Best Regards,
> > > >> > Igor
> > > >> >
> > > >> >
> > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> > [hidden email]>
> > > >> > wrote:
> > > >> >
> > > >> > > Igor,
> > > >> > >
> > > >> > > Yes, cache groups are public API. However, we try to avoid new
> > APIs
> > > >> > > depending on them.
> > > >> > > The main point from my side is that “similar cache group” can be
> > > >> easily
> > > >> > > generalized to “similar distribution”. This way we avoid cache
> > > groups
> > > >> on
> > > >> > > protocol level at virtually no cost.
> > > >> > >
> > > >> > > Vladimir.
> > > >> > >
> > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]>:
> > > >> > >
> > > >> > > > Guys,
> > > >> > > >
> > > >> > > > Can you explain why do we want to avoid Cache groups in
> > protocol?
> > > >> > > >
> > > >> > > > If it's about simplicity of the protocol, then removing cache
> > > groups
> > > >> > will
> > > >> > > > not help much with it - we will still need to include
> > > >> "knownCacheIds"
> > > >> > > > field in request and "cachesWithTheSamePartitioning" field in
> > > >> response.
> > > >> > > > And also, since when do Ignite prefers simplicity over
> > > performance?
> > > >> > > >
> > > >> > > > If it's about not wanting to show internals of Ignite then it
> > > sounds
> > > >> > like
> > > >> > > > a very weak argument to me, since Cache Groups is a public
> thing
> > > >> [1].
> > > >> > > >
> > > >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > > >> > > >
> > > >> > > > Best Regards,
> > > >> > > > Igor
> > > >> > > >
> > > >> > > >
> > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > > >> [hidden email]>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Pavel, Igor,
> > > >> > > > >
> > > >> > > > > This is not very accurate to say that this will not save
> > memory.
> > > >> In
> > > >> > > > > practice we observed a number of OOME issues on the
> > server-side
> > > >> due
> > > >> > to
> > > >> > > > many
> > > >> > > > > caches and it was one of motivations for cache groups
> (another
> > > one
> > > >> > disk
> > > >> > > > > access optimizations). On the other hand, I agree that we'd
> > > >> better to
> > > >> > > > avoid
> > > >> > > > > cache groups in the protocol because this is internal
> > > >> implementation
> > > >> > > > detail
> > > >> > > > > which is likely (I hope so) to be changed in future.
> > > >> > > > >
> > > >> > > > > So I have another proposal - let's track caches with the
> same
> > > >> > affinity
> > > >> > > > > distribution instead. That is, normally most of PARTITIONED
> > > caches
> > > >> > will
> > > >> > > > > have very few variants of configuration: it will be
> Rendezvous
> > > >> > affinity
> > > >> > > > > function, most likely with default partition number and with
> > 1-2
> > > >> > > backups
> > > >> > > > at
> > > >> > > > > most. So when affinity distribution for specific cache is
> > > >> requested,
> > > >> > we
> > > >> > > > can
> > > >> > > > > append to the response *list of caches with the same
> > > >> distribution*.
> > > >> > > I.e.:
> > > >> > > > >
> > > >> > > > > class AffinityResponse {
> > > >> > > > >     Object distribution;    // Actual distribution
> > > >> > > > >     List<Integer> cacheIds; // Caches with similar
> > distribution
> > > >> > > > > }
> > > >> > > > >
> > > >> > > > > Makes sense?
> > > >> > > > >
> > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> > > >> [hidden email]>
> > > >> > > > > wrote:
> > > >> > > > >
> > > >> > > > > > Igor, I have a feeling that we should omit Cache Group
> stuff
> > > >> from
> > > >> > the
> > > >> > > > > > protocol.
> > > >> > > > > > It is a rare use case and even then dealing with them on
> > > client
> > > >> > > barely
> > > >> > > > > > saves some memory.
> > > >> > > > > >
> > > >> > > > > > We can keep it simple and have partition map per cacheId.
> > > >> Thoughts?
> > > >> > > > > >
> > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> > > [hidden email]>
> > > >> > > wrote:
> > > >> > > > > >
> > > >> > > > > > > Guys, I've updated the proposal once again [1], so
> 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> > > >> [hidden email]>
> > > >> > > > > wrote:
> > > >> > > > > > >
> > > >> > > > > > > > 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.
> > > >> > > > > > > >> > > > > > > >
> > > >> > > > > > > >> > > > > > >
> > > >> > > > > > > >> > > > > >
> > > >> > > > > > > >> > > > >
> > > >> > > > > > > >> > > >
> > > >> > > > > > > >> > >
> > > >> > > > > > > >> >
> > > >> > > > > > > >>
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

[Igor Sapego-2]

I can propose two improvements here:

1. A simple one. Lets introduce maxConnectionNumber parameter
in ClientConfiguration. As it is easy to implement it may be introduced
together with the new feature to give user an additional control.

2. Asynchronous connection establishment. In this case startup method
of a client returns control to user once it have established at least one
connection. Other connections established in background by a separate
thread. This one is harder to implement and maybe it makes sense to add
it as a separate feature.

Best Regards,
Igor


On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <[hidden email]> wrote:

> Hi,
>
> I'm in progress of implementing this IEP for Ignite.NET, and I have
> concerns about the following:
>
> > On thin client startup it connects to all nodes provided by client
> configuration
>
> Should we, at least, make this behavior optional?
>
> One of the benefits of thin client is quick startup/connect time and low
> resource usage.
> Adding "connect all" behavior can negate those benefits, especially on
> large clusters.
>
> Thoughts?
>
> On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]> wrote:
>
> > Guys, I've updated the IEP page [1] once again.
> >
> > Please, pay attention to sections Cache affinity mapping acquiring
> > (4.a, format of Cache Partitions Request) and Changes to cache
> > operations with single key (3 and 4, algorithm).
> >
> > Long story short, I've decided to add some additional data to Cache
> > Partitions Response, so that client can determine how to calculate
> > partition for a given key properly.
> >
> > [1] -
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <[hidden email]>
> > wrote:
> >
> > > Looks good to me.
> > >
> > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]> wrote:
> > >
> > > > I've updated IEP page: [1]
> > > >
> > > > What do you think now? To me it looks cleaner.
> > > >
> > > > [1] -
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]>
> wrote:
> > > >
> > > > > Ok, I understand now. I'll try updating IEP according to this
> > proposal
> > > > and
> > > > > notify you guys.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
> [hidden email]
> > >
> > > > > wrote:
> > > > >
> > > > >> Igor,
> > > > >>
> > > > >> My idea is simply to add the list of caches with the same
> > distribution
> > > > to
> > > > >> the end of partition response. Client can use this information to
> > > > populate
> > > > >> partition info for more caches in a single request.
> > > > >>
> > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > > >>
> > > > >> > Vladimir,
> > > > >> >
> > > > >> > So correct me if I'm wrong, what you propose is to avoid
> > mentioning
> > > > >> > of cache groups, and use instead of "cache group" term something
> > > like
> > > > >> > "distribution"? Or do you propose some changes in protocol? If
> so,
> > > can
> > > > >> > you briefly explain, what kind of changes they are?
> > > > >> >
> > > > >> > Best Regards,
> > > > >> > Igor
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> > > [hidden email]>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Igor,
> > > > >> > >
> > > > >> > > Yes, cache groups are public API. However, we try to avoid new
> > > APIs
> > > > >> > > depending on them.
> > > > >> > > The main point from my side is that “similar cache group” can
> be
> > > > >> easily
> > > > >> > > generalized to “similar distribution”. This way we avoid cache
> > > > groups
> > > > >> on
> > > > >> > > protocol level at virtually no cost.
> > > > >> > >
> > > > >> > > Vladimir.
> > > > >> > >
> > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <[hidden email]
> >:
> > > > >> > >
> > > > >> > > > Guys,
> > > > >> > > >
> > > > >> > > > Can you explain why do we want to avoid Cache groups in
> > > protocol?
> > > > >> > > >
> > > > >> > > > If it's about simplicity of the protocol, then removing
> cache
> > > > groups
> > > > >> > will
> > > > >> > > > not help much with it - we will still need to include
> > > > >> "knownCacheIds"
> > > > >> > > > field in request and "cachesWithTheSamePartitioning" field
> in
> > > > >> response.
> > > > >> > > > And also, since when do Ignite prefers simplicity over
> > > > performance?
> > > > >> > > >
> > > > >> > > > If it's about not wanting to show internals of Ignite then
> it
> > > > sounds
> > > > >> > like
> > > > >> > > > a very weak argument to me, since Cache Groups is a public
> > thing
> > > > >> [1].
> > > > >> > > >
> > > > >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > > > >> > > >
> > > > >> > > > Best Regards,
> > > > >> > > > Igor
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > > > >> [hidden email]>
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > > > Pavel, Igor,
> > > > >> > > > >
> > > > >> > > > > This is not very accurate to say that this will not save
> > > memory.
> > > > >> In
> > > > >> > > > > practice we observed a number of OOME issues on the
> > > server-side
> > > > >> due
> > > > >> > to
> > > > >> > > > many
> > > > >> > > > > caches and it was one of motivations for cache groups
> > (another
> > > > one
> > > > >> > disk
> > > > >> > > > > access optimizations). On the other hand, I agree that
> we'd
> > > > >> better to
> > > > >> > > > avoid
> > > > >> > > > > cache groups in the protocol because this is internal
> > > > >> implementation
> > > > >> > > > detail
> > > > >> > > > > which is likely (I hope so) to be changed in future.
> > > > >> > > > >
> > > > >> > > > > So I have another proposal - let's track caches with the
> > same
> > > > >> > affinity
> > > > >> > > > > distribution instead. That is, normally most of
> PARTITIONED
> > > > caches
> > > > >> > will
> > > > >> > > > > have very few variants of configuration: it will be
> > Rendezvous
> > > > >> > affinity
> > > > >> > > > > function, most likely with default partition number and
> with
> > > 1-2
> > > > >> > > backups
> > > > >> > > > at
> > > > >> > > > > most. So when affinity distribution for specific cache is
> > > > >> requested,
> > > > >> > we
> > > > >> > > > can
> > > > >> > > > > append to the response *list of caches with the same
> > > > >> distribution*.
> > > > >> > > I.e.:
> > > > >> > > > >
> > > > >> > > > > class AffinityResponse {
> > > > >> > > > >     Object distribution;    // Actual distribution
> > > > >> > > > >     List<Integer> cacheIds; // Caches with similar
> > > distribution
> > > > >> > > > > }
> > > > >> > > > >
> > > > >> > > > > Makes sense?
> > > > >> > > > >
> > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> > > > >> [hidden email]>
> > > > >> > > > > wrote:
> > > > >> > > > >
> > > > >> > > > > > Igor, I have a feeling that we should omit Cache Group
> > stuff
> > > > >> from
> > > > >> > the
> > > > >> > > > > > protocol.
> > > > >> > > > > > It is a rare use case and even then dealing with them on
> > > > client
> > > > >> > > barely
> > > > >> > > > > > saves some memory.
> > > > >> > > > > >
> > > > >> > > > > > We can keep it simple and have partition map per
> cacheId.
> > > > >> Thoughts?
> > > > >> > > > > >
> > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> > > > [hidden email]>
> > > > >> > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > > Guys, I've updated the proposal once again [1], so
> > 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> > > > >> [hidden email]>
> > > > >> > > > > wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > 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.
> > > > >> > > > > > > >> > > > > > > >
> > > > >> > > > > > > >> > > > > > >
> > > > >> > > > > > > >> > > > > >
> > > > >> > > > > > > >> > > > >
> > > > >> > > > > > > >> > > >
> > > > >> > > > > > > >> > >
> > > > >> > > > > > > >> >
> > > > >> > > > > > > >>
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

>  maxConnectionNumber parameter
What's the idea? Follow the Best Effor Affinity logic, but establish up to
N connections?

On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego <[hidden email]> wrote:

> I can propose two improvements here:
>
> 1. A simple one. Lets introduce maxConnectionNumber parameter
> in ClientConfiguration. As it is easy to implement it may be introduced
> together with the new feature to give user an additional control.
>
> 2. Asynchronous connection establishment. In this case startup method
> of a client returns control to user once it have established at least one
> connection. Other connections established in background by a separate
> thread. This one is harder to implement and maybe it makes sense to add
> it as a separate feature.
>
> Best Regards,
> Igor
>
>
> On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <[hidden email]>
> wrote:
>
> > Hi,
> >
> > I'm in progress of implementing this IEP for Ignite.NET, and I have
> > concerns about the following:
> >
> > > On thin client startup it connects to all nodes provided by client
> > configuration
> >
> > Should we, at least, make this behavior optional?
> >
> > One of the benefits of thin client is quick startup/connect time and low
> > resource usage.
> > Adding "connect all" behavior can negate those benefits, especially on
> > large clusters.
> >
> > Thoughts?
> >
> > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]> wrote:
> >
> > > Guys, I've updated the IEP page [1] once again.
> > >
> > > Please, pay attention to sections Cache affinity mapping acquiring
> > > (4.a, format of Cache Partitions Request) and Changes to cache
> > > operations with single key (3 and 4, algorithm).
> > >
> > > Long story short, I've decided to add some additional data to Cache
> > > Partitions Response, so that client can determine how to calculate
> > > partition for a given key properly.
> > >
> > > [1] -
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <[hidden email]>
> > > wrote:
> > >
> > > > Looks good to me.
> > > >
> > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]>
> wrote:
> > > >
> > > > > I've updated IEP page: [1]
> > > > >
> > > > > What do you think now? To me it looks cleaner.
> > > > >
> > > > > [1] -
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]>
> > wrote:
> > > > >
> > > > > > Ok, I understand now. I'll try updating IEP according to this
> > > proposal
> > > > > and
> > > > > > notify you guys.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
> > [hidden email]
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Igor,
> > > > > >>
> > > > > >> My idea is simply to add the list of caches with the same
> > > distribution
> > > > > to
> > > > > >> the end of partition response. Client can use this information
> to
> > > > > populate
> > > > > >> partition info for more caches in a single request.
> > > > > >>
> > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <[hidden email]>
> > > > wrote:
> > > > > >>
> > > > > >> > Vladimir,
> > > > > >> >
> > > > > >> > So correct me if I'm wrong, what you propose is to avoid
> > > mentioning
> > > > > >> > of cache groups, and use instead of "cache group" term
> something
> > > > like
> > > > > >> > "distribution"? Or do you propose some changes in protocol? If
> > so,
> > > > can
> > > > > >> > you briefly explain, what kind of changes they are?
> > > > > >> >
> > > > > >> > Best Regards,
> > > > > >> > Igor
> > > > > >> >
> > > > > >> >
> > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> > > > [hidden email]>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > Igor,
> > > > > >> > >
> > > > > >> > > Yes, cache groups are public API. However, we try to avoid
> new
> > > > APIs
> > > > > >> > > depending on them.
> > > > > >> > > The main point from my side is that “similar cache group”
> can
> > be
> > > > > >> easily
> > > > > >> > > generalized to “similar distribution”. This way we avoid
> cache
> > > > > groups
> > > > > >> on
> > > > > >> > > protocol level at virtually no cost.
> > > > > >> > >
> > > > > >> > > Vladimir.
> > > > > >> > >
> > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <
> [hidden email]
> > >:
> > > > > >> > >
> > > > > >> > > > Guys,
> > > > > >> > > >
> > > > > >> > > > Can you explain why do we want to avoid Cache groups in
> > > > protocol?
> > > > > >> > > >
> > > > > >> > > > If it's about simplicity of the protocol, then removing
> > cache
> > > > > groups
> > > > > >> > will
> > > > > >> > > > not help much with it - we will still need to include
> > > > > >> "knownCacheIds"
> > > > > >> > > > field in request and "cachesWithTheSamePartitioning" field
> > in
> > > > > >> response.
> > > > > >> > > > And also, since when do Ignite prefers simplicity over
> > > > > performance?
> > > > > >> > > >
> > > > > >> > > > If it's about not wanting to show internals of Ignite then
> > it
> > > > > sounds
> > > > > >> > like
> > > > > >> > > > a very weak argument to me, since Cache Groups is a public
> > > thing
> > > > > >> [1].
> > > > > >> > > >
> > > > > >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > > > > >> > > >
> > > > > >> > > > Best Regards,
> > > > > >> > > > Igor
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > > > > >> [hidden email]>
> > > > > >> > > > wrote:
> > > > > >> > > >
> > > > > >> > > > > Pavel, Igor,
> > > > > >> > > > >
> > > > > >> > > > > This is not very accurate to say that this will not save
> > > > memory.
> > > > > >> In
> > > > > >> > > > > practice we observed a number of OOME issues on the
> > > > server-side
> > > > > >> due
> > > > > >> > to
> > > > > >> > > > many
> > > > > >> > > > > caches and it was one of motivations for cache groups
> > > (another
> > > > > one
> > > > > >> > disk
> > > > > >> > > > > access optimizations). On the other hand, I agree that
> > we'd
> > > > > >> better to
> > > > > >> > > > avoid
> > > > > >> > > > > cache groups in the protocol because this is internal
> > > > > >> implementation
> > > > > >> > > > detail
> > > > > >> > > > > which is likely (I hope so) to be changed in future.
> > > > > >> > > > >
> > > > > >> > > > > So I have another proposal - let's track caches with the
> > > same
> > > > > >> > affinity
> > > > > >> > > > > distribution instead. That is, normally most of
> > PARTITIONED
> > > > > caches
> > > > > >> > will
> > > > > >> > > > > have very few variants of configuration: it will be
> > > Rendezvous
> > > > > >> > affinity
> > > > > >> > > > > function, most likely with default partition number and
> > with
> > > > 1-2
> > > > > >> > > backups
> > > > > >> > > > at
> > > > > >> > > > > most. So when affinity distribution for specific cache
> is
> > > > > >> requested,
> > > > > >> > we
> > > > > >> > > > can
> > > > > >> > > > > append to the response *list of caches with the same
> > > > > >> distribution*.
> > > > > >> > > I.e.:
> > > > > >> > > > >
> > > > > >> > > > > class AffinityResponse {
> > > > > >> > > > >     Object distribution;    // Actual distribution
> > > > > >> > > > >     List<Integer> cacheIds; // Caches with similar
> > > > distribution
> > > > > >> > > > > }
> > > > > >> > > > >
> > > > > >> > > > > Makes sense?
> > > > > >> > > > >
> > > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> > > > > >> [hidden email]>
> > > > > >> > > > > wrote:
> > > > > >> > > > >
> > > > > >> > > > > > Igor, I have a feeling that we should omit Cache Group
> > > stuff
> > > > > >> from
> > > > > >> > the
> > > > > >> > > > > > protocol.
> > > > > >> > > > > > It is a rare use case and even then dealing with them
> on
> > > > > client
> > > > > >> > > barely
> > > > > >> > > > > > saves some memory.
> > > > > >> > > > > >
> > > > > >> > > > > > We can keep it simple and have partition map per
> > cacheId.
> > > > > >> Thoughts?
> > > > > >> > > > > >
> > > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> > > > > [hidden email]>
> > > > > >> > > wrote:
> > > > > >> > > > > >
> > > > > >> > > > > > > Guys, I've updated the proposal once again [1], so
> > > 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> > > > > >> [hidden email]>
> > > > > >> > > > > wrote:
> > > > > >> > > > > > >
> > > > > >> > > > > > > > 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.
> > > > > >> > > > > > > >> > > > > > > >
> > > > > >> > > > > > > >> > > > > > >
> > > > > >> > > > > > > >> > > > > >
> > > > > >> > > > > > > >> > > > >
> > > > > >> > > > > > > >> > > >
> > > > > >> > > > > > > >> > >
> > > > > >> > > > > > > >> >
> > > > > >> > > > > > > >>
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

Pavel,

That's right. Do you have other suggestions or objections?

Best Regards,
Igor


On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn <[hidden email]> wrote:

> >  maxConnectionNumber parameter
> What's the idea? Follow the Best Effor Affinity logic, but establish up to
> N connections?
>
> On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego <[hidden email]> wrote:
>
> > I can propose two improvements here:
> >
> > 1. A simple one. Lets introduce maxConnectionNumber parameter
> > in ClientConfiguration. As it is easy to implement it may be introduced
> > together with the new feature to give user an additional control.
> >
> > 2. Asynchronous connection establishment. In this case startup method
> > of a client returns control to user once it have established at least one
> > connection. Other connections established in background by a separate
> > thread. This one is harder to implement and maybe it makes sense to add
> > it as a separate feature.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > I'm in progress of implementing this IEP for Ignite.NET, and I have
> > > concerns about the following:
> > >
> > > > On thin client startup it connects to all nodes provided by client
> > > configuration
> > >
> > > Should we, at least, make this behavior optional?
> > >
> > > One of the benefits of thin client is quick startup/connect time and
> low
> > > resource usage.
> > > Adding "connect all" behavior can negate those benefits, especially on
> > > large clusters.
> > >
> > > Thoughts?
> > >
> > > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]>
> wrote:
> > >
> > > > Guys, I've updated the IEP page [1] once again.
> > > >
> > > > Please, pay attention to sections Cache affinity mapping acquiring
> > > > (4.a, format of Cache Partitions Request) and Changes to cache
> > > > operations with single key (3 and 4, algorithm).
> > > >
> > > > Long story short, I've decided to add some additional data to Cache
> > > > Partitions Response, so that client can determine how to calculate
> > > > partition for a given key properly.
> > > >
> > > > [1] -
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <[hidden email]>
> > > > wrote:
> > > >
> > > > > Looks good to me.
> > > > >
> > > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]>
> > wrote:
> > > > >
> > > > > > I've updated IEP page: [1]
> > > > > >
> > > > > > What do you think now? To me it looks cleaner.
> > > > > >
> > > > > > [1] -
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > > > >
> > > > > > > Ok, I understand now. I'll try updating IEP according to this
> > > > proposal
> > > > > > and
> > > > > > > notify you guys.
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Igor
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
> > > [hidden email]
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Igor,
> > > > > > >>
> > > > > > >> My idea is simply to add the list of caches with the same
> > > > distribution
> > > > > > to
> > > > > > >> the end of partition response. Client can use this information
> > to
> > > > > > populate
> > > > > > >> partition info for more caches in a single request.
> > > > > > >>
> > > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <
> [hidden email]>
> > > > > wrote:
> > > > > > >>
> > > > > > >> > Vladimir,
> > > > > > >> >
> > > > > > >> > So correct me if I'm wrong, what you propose is to avoid
> > > > mentioning
> > > > > > >> > of cache groups, and use instead of "cache group" term
> > something
> > > > > like
> > > > > > >> > "distribution"? Or do you propose some changes in protocol?
> If
> > > so,
> > > > > can
> > > > > > >> > you briefly explain, what kind of changes they are?
> > > > > > >> >
> > > > > > >> > Best Regards,
> > > > > > >> > Igor
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> > > > > [hidden email]>
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> > > Igor,
> > > > > > >> > >
> > > > > > >> > > Yes, cache groups are public API. However, we try to avoid
> > new
> > > > > APIs
> > > > > > >> > > depending on them.
> > > > > > >> > > The main point from my side is that “similar cache group”
> > can
> > > be
> > > > > > >> easily
> > > > > > >> > > generalized to “similar distribution”. This way we avoid
> > cache
> > > > > > groups
> > > > > > >> on
> > > > > > >> > > protocol level at virtually no cost.
> > > > > > >> > >
> > > > > > >> > > Vladimir.
> > > > > > >> > >
> > > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <
> > [hidden email]
> > > >:
> > > > > > >> > >
> > > > > > >> > > > Guys,
> > > > > > >> > > >
> > > > > > >> > > > Can you explain why do we want to avoid Cache groups in
> > > > > protocol?
> > > > > > >> > > >
> > > > > > >> > > > If it's about simplicity of the protocol, then removing
> > > cache
> > > > > > groups
> > > > > > >> > will
> > > > > > >> > > > not help much with it - we will still need to include
> > > > > > >> "knownCacheIds"
> > > > > > >> > > > field in request and "cachesWithTheSamePartitioning"
> field
> > > in
> > > > > > >> response.
> > > > > > >> > > > And also, since when do Ignite prefers simplicity over
> > > > > > performance?
> > > > > > >> > > >
> > > > > > >> > > > If it's about not wanting to show internals of Ignite
> then
> > > it
> > > > > > sounds
> > > > > > >> > like
> > > > > > >> > > > a very weak argument to me, since Cache Groups is a
> public
> > > > thing
> > > > > > >> [1].
> > > > > > >> > > >
> > > > > > >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups
> > > > > > >> > > >
> > > > > > >> > > > Best Regards,
> > > > > > >> > > > Igor
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > > > > > >> [hidden email]>
> > > > > > >> > > > wrote:
> > > > > > >> > > >
> > > > > > >> > > > > Pavel, Igor,
> > > > > > >> > > > >
> > > > > > >> > > > > This is not very accurate to say that this will not
> save
> > > > > memory.
> > > > > > >> In
> > > > > > >> > > > > practice we observed a number of OOME issues on the
> > > > > server-side
> > > > > > >> due
> > > > > > >> > to
> > > > > > >> > > > many
> > > > > > >> > > > > caches and it was one of motivations for cache groups
> > > > (another
> > > > > > one
> > > > > > >> > disk
> > > > > > >> > > > > access optimizations). On the other hand, I agree that
> > > we'd
> > > > > > >> better to
> > > > > > >> > > > avoid
> > > > > > >> > > > > cache groups in the protocol because this is internal
> > > > > > >> implementation
> > > > > > >> > > > detail
> > > > > > >> > > > > which is likely (I hope so) to be changed in future.
> > > > > > >> > > > >
> > > > > > >> > > > > So I have another proposal - let's track caches with
> the
> > > > same
> > > > > > >> > affinity
> > > > > > >> > > > > distribution instead. That is, normally most of
> > > PARTITIONED
> > > > > > caches
> > > > > > >> > will
> > > > > > >> > > > > have very few variants of configuration: it will be
> > > > Rendezvous
> > > > > > >> > affinity
> > > > > > >> > > > > function, most likely with default partition number
> and
> > > with
> > > > > 1-2
> > > > > > >> > > backups
> > > > > > >> > > > at
> > > > > > >> > > > > most. So when affinity distribution for specific cache
> > is
> > > > > > >> requested,
> > > > > > >> > we
> > > > > > >> > > > can
> > > > > > >> > > > > append to the response *list of caches with the same
> > > > > > >> distribution*.
> > > > > > >> > > I.e.:
> > > > > > >> > > > >
> > > > > > >> > > > > class AffinityResponse {
> > > > > > >> > > > >     Object distribution;    // Actual distribution
> > > > > > >> > > > >     List<Integer> cacheIds; // Caches with similar
> > > > > distribution
> > > > > > >> > > > > }
> > > > > > >> > > > >
> > > > > > >> > > > > Makes sense?
> > > > > > >> > > > >
> > > > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> > > > > > >> [hidden email]>
> > > > > > >> > > > > wrote:
> > > > > > >> > > > >
> > > > > > >> > > > > > Igor, I have a feeling that we should omit Cache
> Group
> > > > stuff
> > > > > > >> from
> > > > > > >> > the
> > > > > > >> > > > > > protocol.
> > > > > > >> > > > > > It is a rare use case and even then dealing with
> them
> > on
> > > > > > client
> > > > > > >> > > barely
> > > > > > >> > > > > > saves some memory.
> > > > > > >> > > > > >
> > > > > > >> > > > > > We can keep it simple and have partition map per
> > > cacheId.
> > > > > > >> Thoughts?
> > > > > > >> > > > > >
> > > > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> > > > > > [hidden email]>
> > > > > > >> > > wrote:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > Guys, I've updated the proposal once again [1], so
> > > > 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> > > > > > >> [hidden email]>
> > > > > > >> > > > > wrote:
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > > 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.
> > > > > > >> > > > > > > >> > > > > > > >
> > > > > > >> > > > > > > >> > > > > > >
> > > > > > >> > > > > > > >> > > > > >
> > > > > > >> > > > > > > >> > > > >
> > > > > > >> > > > > > > >> > > >
> > > > > > >> > > > > > > >> > >
> > > > > > >> > > > > > > >> >
> > > > > > >> > > > > > > >>
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

My suggestion is a boolean flag in client configuration:
DisableAffinityAwareness
And use old random/round-robin behavior with only one active connection.

On Mon, Mar 11, 2019 at 1:36 PM Igor Sapego <[hidden email]> wrote:

> Pavel,
>
> That's right. Do you have other suggestions or objections?
>
> Best Regards,
> Igor
>
>
> On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn <[hidden email]>
> wrote:
>
> > >  maxConnectionNumber parameter
> > What's the idea? Follow the Best Effor Affinity logic, but establish up
> to
> > N connections?
> >
> > On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego <[hidden email]> wrote:
> >
> > > I can propose two improvements here:
> > >
> > > 1. A simple one. Lets introduce maxConnectionNumber parameter
> > > in ClientConfiguration. As it is easy to implement it may be introduced
> > > together with the new feature to give user an additional control.
> > >
> > > 2. Asynchronous connection establishment. In this case startup method
> > > of a client returns control to user once it have established at least
> one
> > > connection. Other connections established in background by a separate
> > > thread. This one is harder to implement and maybe it makes sense to add
> > > it as a separate feature.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <[hidden email]>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm in progress of implementing this IEP for Ignite.NET, and I have
> > > > concerns about the following:
> > > >
> > > > > On thin client startup it connects to all nodes provided by client
> > > > configuration
> > > >
> > > > Should we, at least, make this behavior optional?
> > > >
> > > > One of the benefits of thin client is quick startup/connect time and
> > low
> > > > resource usage.
> > > > Adding "connect all" behavior can negate those benefits, especially
> on
> > > > large clusters.
> > > >
> > > > Thoughts?
> > > >
> > > > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]>
> > wrote:
> > > >
> > > > > Guys, I've updated the IEP page [1] once again.
> > > > >
> > > > > Please, pay attention to sections Cache affinity mapping acquiring
> > > > > (4.a, format of Cache Partitions Request) and Changes to cache
> > > > > operations with single key (3 and 4, algorithm).
> > > > >
> > > > > Long story short, I've decided to add some additional data to Cache
> > > > > Partitions Response, so that client can determine how to calculate
> > > > > partition for a given key properly.
> > > > >
> > > > > [1] -
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <
> [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Looks good to me.
> > > > > >
> > > > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > > > >
> > > > > > > I've updated IEP page: [1]
> > > > > > >
> > > > > > > What do you think now? To me it looks cleaner.
> > > > > > >
> > > > > > > [1] -
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Igor
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <[hidden email]
> >
> > > > wrote:
> > > > > > >
> > > > > > > > Ok, I understand now. I'll try updating IEP according to this
> > > > > proposal
> > > > > > > and
> > > > > > > > notify you guys.
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Igor
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
> > > > [hidden email]
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Igor,
> > > > > > > >>
> > > > > > > >> My idea is simply to add the list of caches with the same
> > > > > distribution
> > > > > > > to
> > > > > > > >> the end of partition response. Client can use this
> information
> > > to
> > > > > > > populate
> > > > > > > >> partition info for more caches in a single request.
> > > > > > > >>
> > > > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <
> > [hidden email]>
> > > > > > wrote:
> > > > > > > >>
> > > > > > > >> > Vladimir,
> > > > > > > >> >
> > > > > > > >> > So correct me if I'm wrong, what you propose is to avoid
> > > > > mentioning
> > > > > > > >> > of cache groups, and use instead of "cache group" term
> > > something
> > > > > > like
> > > > > > > >> > "distribution"? Or do you propose some changes in
> protocol?
> > If
> > > > so,
> > > > > > can
> > > > > > > >> > you briefly explain, what kind of changes they are?
> > > > > > > >> >
> > > > > > > >> > Best Regards,
> > > > > > > >> > Igor
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> > > > > > [hidden email]>
> > > > > > > >> > wrote:
> > > > > > > >> >
> > > > > > > >> > > Igor,
> > > > > > > >> > >
> > > > > > > >> > > Yes, cache groups are public API. However, we try to
> avoid
> > > new
> > > > > > APIs
> > > > > > > >> > > depending on them.
> > > > > > > >> > > The main point from my side is that “similar cache
> group”
> > > can
> > > > be
> > > > > > > >> easily
> > > > > > > >> > > generalized to “similar distribution”. This way we avoid
> > > cache
> > > > > > > groups
> > > > > > > >> on
> > > > > > > >> > > protocol level at virtually no cost.
> > > > > > > >> > >
> > > > > > > >> > > Vladimir.
> > > > > > > >> > >
> > > > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <
> > > [hidden email]
> > > > >:
> > > > > > > >> > >
> > > > > > > >> > > > Guys,
> > > > > > > >> > > >
> > > > > > > >> > > > Can you explain why do we want to avoid Cache groups
> in
> > > > > > protocol?
> > > > > > > >> > > >
> > > > > > > >> > > > If it's about simplicity of the protocol, then
> removing
> > > > cache
> > > > > > > groups
> > > > > > > >> > will
> > > > > > > >> > > > not help much with it - we will still need to include
> > > > > > > >> "knownCacheIds"
> > > > > > > >> > > > field in request and "cachesWithTheSamePartitioning"
> > field
> > > > in
> > > > > > > >> response.
> > > > > > > >> > > > And also, since when do Ignite prefers simplicity over
> > > > > > > performance?
> > > > > > > >> > > >
> > > > > > > >> > > > If it's about not wanting to show internals of Ignite
> > then
> > > > it
> > > > > > > sounds
> > > > > > > >> > like
> > > > > > > >> > > > a very weak argument to me, since Cache Groups is a
> > public
> > > > > thing
> > > > > > > >> [1].
> > > > > > > >> > > >
> > > > > > > >> > > > [1] -
> https://apacheignite.readme.io/docs/cache-groups
> > > > > > > >> > > >
> > > > > > > >> > > > Best Regards,
> > > > > > > >> > > > Igor
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > > > > > > >> [hidden email]>
> > > > > > > >> > > > wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > > Pavel, Igor,
> > > > > > > >> > > > >
> > > > > > > >> > > > > This is not very accurate to say that this will not
> > save
> > > > > > memory.
> > > > > > > >> In
> > > > > > > >> > > > > practice we observed a number of OOME issues on the
> > > > > > server-side
> > > > > > > >> due
> > > > > > > >> > to
> > > > > > > >> > > > many
> > > > > > > >> > > > > caches and it was one of motivations for cache
> groups
> > > > > (another
> > > > > > > one
> > > > > > > >> > disk
> > > > > > > >> > > > > access optimizations). On the other hand, I agree
> that
> > > > we'd
> > > > > > > >> better to
> > > > > > > >> > > > avoid
> > > > > > > >> > > > > cache groups in the protocol because this is
> internal
> > > > > > > >> implementation
> > > > > > > >> > > > detail
> > > > > > > >> > > > > which is likely (I hope so) to be changed in future.
> > > > > > > >> > > > >
> > > > > > > >> > > > > So I have another proposal - let's track caches with
> > the
> > > > > same
> > > > > > > >> > affinity
> > > > > > > >> > > > > distribution instead. That is, normally most of
> > > > PARTITIONED
> > > > > > > caches
> > > > > > > >> > will
> > > > > > > >> > > > > have very few variants of configuration: it will be
> > > > > Rendezvous
> > > > > > > >> > affinity
> > > > > > > >> > > > > function, most likely with default partition number
> > and
> > > > with
> > > > > > 1-2
> > > > > > > >> > > backups
> > > > > > > >> > > > at
> > > > > > > >> > > > > most. So when affinity distribution for specific
> cache
> > > is
> > > > > > > >> requested,
> > > > > > > >> > we
> > > > > > > >> > > > can
> > > > > > > >> > > > > append to the response *list of caches with the same
> > > > > > > >> distribution*.
> > > > > > > >> > > I.e.:
> > > > > > > >> > > > >
> > > > > > > >> > > > > class AffinityResponse {
> > > > > > > >> > > > >     Object distribution;    // Actual distribution
> > > > > > > >> > > > >     List<Integer> cacheIds; // Caches with similar
> > > > > > distribution
> > > > > > > >> > > > > }
> > > > > > > >> > > > >
> > > > > > > >> > > > > Makes sense?
> > > > > > > >> > > > >
> > > > > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> > > > > > > >> [hidden email]>
> > > > > > > >> > > > > wrote:
> > > > > > > >> > > > >
> > > > > > > >> > > > > > Igor, I have a feeling that we should omit Cache
> > Group
> > > > > stuff
> > > > > > > >> from
> > > > > > > >> > the
> > > > > > > >> > > > > > protocol.
> > > > > > > >> > > > > > It is a rare use case and even then dealing with
> > them
> > > on
> > > > > > > client
> > > > > > > >> > > barely
> > > > > > > >> > > > > > saves some memory.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > We can keep it simple and have partition map per
> > > > cacheId.
> > > > > > > >> Thoughts?
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> > > > > > > [hidden email]>
> > > > > > > >> > > wrote:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > Guys, I've updated the proposal once again [1],
> so
> > > > > 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> > > > > > > >> [hidden email]>
> > > > > > > >> > > > > wrote:
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > > 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.
> > > > > > > >> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > >> > > > >
> > > > > > > >> > > > > > > >> > > >
> > > > > > > >> > > > > > > >> > >
> > > > > > > >> > > > > > > >> >
> > > > > > > >> > > > > > > >>
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

Well, yes, this looks like a simplest solution. Let's implement it for the
beginning and set this feature to "false" by default, as this feature looks
complex, probably error-prone, and should be considered in a "beta"
state for the first release.

Best Regards,
Igor


On Mon, Mar 11, 2019 at 8:04 PM Pavel Tupitsyn <[hidden email]> wrote:

> My suggestion is a boolean flag in client configuration:
> DisableAffinityAwareness
> And use old random/round-robin behavior with only one active connection.
>
> On Mon, Mar 11, 2019 at 1:36 PM Igor Sapego <[hidden email]> wrote:
>
> > Pavel,
> >
> > That's right. Do you have other suggestions or objections?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn <[hidden email]>
> > wrote:
> >
> > > >  maxConnectionNumber parameter
> > > What's the idea? Follow the Best Effor Affinity logic, but establish up
> > to
> > > N connections?
> > >
> > > On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego <[hidden email]> wrote:
> > >
> > > > I can propose two improvements here:
> > > >
> > > > 1. A simple one. Lets introduce maxConnectionNumber parameter
> > > > in ClientConfiguration. As it is easy to implement it may be
> introduced
> > > > together with the new feature to give user an additional control.
> > > >
> > > > 2. Asynchronous connection establishment. In this case startup method
> > > > of a client returns control to user once it have established at least
> > one
> > > > connection. Other connections established in background by a separate
> > > > thread. This one is harder to implement and maybe it makes sense to
> add
> > > > it as a separate feature.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <[hidden email]>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm in progress of implementing this IEP for Ignite.NET, and I have
> > > > > concerns about the following:
> > > > >
> > > > > > On thin client startup it connects to all nodes provided by
> client
> > > > > configuration
> > > > >
> > > > > Should we, at least, make this behavior optional?
> > > > >
> > > > > One of the benefits of thin client is quick startup/connect time
> and
> > > low
> > > > > resource usage.
> > > > > Adding "connect all" behavior can negate those benefits, especially
> > on
> > > > > large clusters.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]>
> > > wrote:
> > > > >
> > > > > > Guys, I've updated the IEP page [1] once again.
> > > > > >
> > > > > > Please, pay attention to sections Cache affinity mapping
> acquiring
> > > > > > (4.a, format of Cache Partitions Request) and Changes to cache
> > > > > > operations with single key (3 and 4, algorithm).
> > > > > >
> > > > > > Long story short, I've decided to add some additional data to
> Cache
> > > > > > Partitions Response, so that client can determine how to
> calculate
> > > > > > partition for a given key properly.
> > > > > >
> > > > > > [1] -
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <
> > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Looks good to me.
> > > > > > >
> > > > > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <[hidden email]
> >
> > > > wrote:
> > > > > > >
> > > > > > > > I've updated IEP page: [1]
> > > > > > > >
> > > > > > > > What do you think now? To me it looks cleaner.
> > > > > > > >
> > > > > > > > [1] -
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Igor
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <
> [hidden email]
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Ok, I understand now. I'll try updating IEP according to
> this
> > > > > > proposal
> > > > > > > > and
> > > > > > > > > notify you guys.
> > > > > > > > >
> > > > > > > > > Best Regards,
> > > > > > > > > Igor
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
> > > > > [hidden email]
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> Igor,
> > > > > > > > >>
> > > > > > > > >> My idea is simply to add the list of caches with the same
> > > > > > distribution
> > > > > > > > to
> > > > > > > > >> the end of partition response. Client can use this
> > information
> > > > to
> > > > > > > > populate
> > > > > > > > >> partition info for more caches in a single request.
> > > > > > > > >>
> > > > > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <
> > > [hidden email]>
> > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> > Vladimir,
> > > > > > > > >> >
> > > > > > > > >> > So correct me if I'm wrong, what you propose is to avoid
> > > > > > mentioning
> > > > > > > > >> > of cache groups, and use instead of "cache group" term
> > > > something
> > > > > > > like
> > > > > > > > >> > "distribution"? Or do you propose some changes in
> > protocol?
> > > If
> > > > > so,
> > > > > > > can
> > > > > > > > >> > you briefly explain, what kind of changes they are?
> > > > > > > > >> >
> > > > > > > > >> > Best Regards,
> > > > > > > > >> > Igor
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> > > > > > > [hidden email]>
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Igor,
> > > > > > > > >> > >
> > > > > > > > >> > > Yes, cache groups are public API. However, we try to
> > avoid
> > > > new
> > > > > > > APIs
> > > > > > > > >> > > depending on them.
> > > > > > > > >> > > The main point from my side is that “similar cache
> > group”
> > > > can
> > > > > be
> > > > > > > > >> easily
> > > > > > > > >> > > generalized to “similar distribution”. This way we
> avoid
> > > > cache
> > > > > > > > groups
> > > > > > > > >> on
> > > > > > > > >> > > protocol level at virtually no cost.
> > > > > > > > >> > >
> > > > > > > > >> > > Vladimir.
> > > > > > > > >> > >
> > > > > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <
> > > > [hidden email]
> > > > > >:
> > > > > > > > >> > >
> > > > > > > > >> > > > Guys,
> > > > > > > > >> > > >
> > > > > > > > >> > > > Can you explain why do we want to avoid Cache groups
> > in
> > > > > > > protocol?
> > > > > > > > >> > > >
> > > > > > > > >> > > > If it's about simplicity of the protocol, then
> > removing
> > > > > cache
> > > > > > > > groups
> > > > > > > > >> > will
> > > > > > > > >> > > > not help much with it - we will still need to
> include
> > > > > > > > >> "knownCacheIds"
> > > > > > > > >> > > > field in request and "cachesWithTheSamePartitioning"
> > > field
> > > > > in
> > > > > > > > >> response.
> > > > > > > > >> > > > And also, since when do Ignite prefers simplicity
> over
> > > > > > > > performance?
> > > > > > > > >> > > >
> > > > > > > > >> > > > If it's about not wanting to show internals of
> Ignite
> > > then
> > > > > it
> > > > > > > > sounds
> > > > > > > > >> > like
> > > > > > > > >> > > > a very weak argument to me, since Cache Groups is a
> > > public
> > > > > > thing
> > > > > > > > >> [1].
> > > > > > > > >> > > >
> > > > > > > > >> > > > [1] -
> > https://apacheignite.readme.io/docs/cache-groups
> > > > > > > > >> > > >
> > > > > > > > >> > > > Best Regards,
> > > > > > > > >> > > > Igor
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> > > > > > > > >> [hidden email]>
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > > Pavel, Igor,
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > This is not very accurate to say that this will
> not
> > > save
> > > > > > > memory.
> > > > > > > > >> In
> > > > > > > > >> > > > > practice we observed a number of OOME issues on
> the
> > > > > > > server-side
> > > > > > > > >> due
> > > > > > > > >> > to
> > > > > > > > >> > > > many
> > > > > > > > >> > > > > caches and it was one of motivations for cache
> > groups
> > > > > > (another
> > > > > > > > one
> > > > > > > > >> > disk
> > > > > > > > >> > > > > access optimizations). On the other hand, I agree
> > that
> > > > > we'd
> > > > > > > > >> better to
> > > > > > > > >> > > > avoid
> > > > > > > > >> > > > > cache groups in the protocol because this is
> > internal
> > > > > > > > >> implementation
> > > > > > > > >> > > > detail
> > > > > > > > >> > > > > which is likely (I hope so) to be changed in
> future.
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > So I have another proposal - let's track caches
> with
> > > the
> > > > > > same
> > > > > > > > >> > affinity
> > > > > > > > >> > > > > distribution instead. That is, normally most of
> > > > > PARTITIONED
> > > > > > > > caches
> > > > > > > > >> > will
> > > > > > > > >> > > > > have very few variants of configuration: it will
> be
> > > > > > Rendezvous
> > > > > > > > >> > affinity
> > > > > > > > >> > > > > function, most likely with default partition
> number
> > > and
> > > > > with
> > > > > > > 1-2
> > > > > > > > >> > > backups
> > > > > > > > >> > > > at
> > > > > > > > >> > > > > most. So when affinity distribution for specific
> > cache
> > > > is
> > > > > > > > >> requested,
> > > > > > > > >> > we
> > > > > > > > >> > > > can
> > > > > > > > >> > > > > append to the response *list of caches with the
> same
> > > > > > > > >> distribution*.
> > > > > > > > >> > > I.e.:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > class AffinityResponse {
> > > > > > > > >> > > > >     Object distribution;    // Actual distribution
> > > > > > > > >> > > > >     List<Integer> cacheIds; // Caches with similar
> > > > > > > distribution
> > > > > > > > >> > > > > }
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Makes sense?
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> > > > > > > > >> [hidden email]>
> > > > > > > > >> > > > > wrote:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > > Igor, I have a feeling that we should omit Cache
> > > Group
> > > > > > stuff
> > > > > > > > >> from
> > > > > > > > >> > the
> > > > > > > > >> > > > > > protocol.
> > > > > > > > >> > > > > > It is a rare use case and even then dealing with
> > > them
> > > > on
> > > > > > > > client
> > > > > > > > >> > > barely
> > > > > > > > >> > > > > > saves some memory.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > We can keep it simple and have partition map per
> > > > > cacheId.
> > > > > > > > >> Thoughts?
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> > > > > > > > [hidden email]>
> > > > > > > > >> > > wrote:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > Guys, I've updated the proposal once again
> [1],
> > so
> > > > > > 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
> > > > > > > > >> [hidden email]>
> > > > > > > > >> > > > > wrote:
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > > 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.
> > > > > > > > >> > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > >> > > > >
> > > > > > > > >> > > > > > > >> > > >
> > > > > > > > >> > > > > > > >> > >
> > > > > > > > >> > > > > > > >> >
> > > > > > > > >> > > > > > > >>
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Igor Sapego-2]

For the "false" I mean "disable" here.

BTW, I believe we should name this parameter in a positive way:
EnableAffinityAwareness, not disable.

Best Regards,
Igor


On Wed, Mar 13, 2019 at 12:50 PM Igor Sapego <[hidden email]> wrote:

> Well, yes, this looks like a simplest solution. Let's implement it for the
> beginning and set this feature to "false" by default, as this feature looks
> complex, probably error-prone, and should be considered in a "beta"
> state for the first release.
>
> Best Regards,
> Igor
>
>
> On Mon, Mar 11, 2019 at 8:04 PM Pavel Tupitsyn <[hidden email]>
> wrote:
>
>> My suggestion is a boolean flag in client configuration:
>> DisableAffinityAwareness
>> And use old random/round-robin behavior with only one active connection.
>>
>> On Mon, Mar 11, 2019 at 1:36 PM Igor Sapego <[hidden email]> wrote:
>>
>> > Pavel,
>> >
>> > That's right. Do you have other suggestions or objections?
>> >
>> > Best Regards,
>> > Igor
>> >
>> >
>> > On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn <[hidden email]>
>> > wrote:
>> >
>> > > >  maxConnectionNumber parameter
>> > > What's the idea? Follow the Best Effor Affinity logic, but establish
>> up
>> > to
>> > > N connections?
>> > >
>> > > On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego <[hidden email]>
>> wrote:
>> > >
>> > > > I can propose two improvements here:
>> > > >
>> > > > 1. A simple one. Lets introduce maxConnectionNumber parameter
>> > > > in ClientConfiguration. As it is easy to implement it may be
>> introduced
>> > > > together with the new feature to give user an additional control.
>> > > >
>> > > > 2. Asynchronous connection establishment. In this case startup
>> method
>> > > > of a client returns control to user once it have established at
>> least
>> > one
>> > > > connection. Other connections established in background by a
>> separate
>> > > > thread. This one is harder to implement and maybe it makes sense to
>> add
>> > > > it as a separate feature.
>> > > >
>> > > > Best Regards,
>> > > > Igor
>> > > >
>> > > >
>> > > > On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <[hidden email]
>> >
>> > > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > I'm in progress of implementing this IEP for Ignite.NET, and I
>> have
>> > > > > concerns about the following:
>> > > > >
>> > > > > > On thin client startup it connects to all nodes provided by
>> client
>> > > > > configuration
>> > > > >
>> > > > > Should we, at least, make this behavior optional?
>> > > > >
>> > > > > One of the benefits of thin client is quick startup/connect time
>> and
>> > > low
>> > > > > resource usage.
>> > > > > Adding "connect all" behavior can negate those benefits,
>> especially
>> > on
>> > > > > large clusters.
>> > > > >
>> > > > > Thoughts?
>> > > > >
>> > > > > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]>
>> > > wrote:
>> > > > >
>> > > > > > Guys, I've updated the IEP page [1] once again.
>> > > > > >
>> > > > > > Please, pay attention to sections Cache affinity mapping
>> acquiring
>> > > > > > (4.a, format of Cache Partitions Request) and Changes to cache
>> > > > > > operations with single key (3 and 4, algorithm).
>> > > > > >
>> > > > > > Long story short, I've decided to add some additional data to
>> Cache
>> > > > > > Partitions Response, so that client can determine how to
>> calculate
>> > > > > > partition for a given key properly.
>> > > > > >
>> > > > > > [1] -
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>> > > > > >
>> > > > > > Best Regards,
>> > > > > > Igor
>> > > > > >
>> > > > > >
>> > > > > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <
>> > [hidden email]>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Looks good to me.
>> > > > > > >
>> > > > > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <
>> [hidden email]>
>> > > > wrote:
>> > > > > > >
>> > > > > > > > I've updated IEP page: [1]
>> > > > > > > >
>> > > > > > > > What do you think now? To me it looks cleaner.
>> > > > > > > >
>> > > > > > > > [1] -
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>> > > > > > > >
>> > > > > > > > Best Regards,
>> > > > > > > > Igor
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <
>> [hidden email]
>> > >
>> > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Ok, I understand now. I'll try updating IEP according to
>> this
>> > > > > > proposal
>> > > > > > > > and
>> > > > > > > > > notify you guys.
>> > > > > > > > >
>> > > > > > > > > Best Regards,
>> > > > > > > > > Igor
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
>> > > > > [hidden email]
>> > > > > > >
>> > > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > >> Igor,
>> > > > > > > > >>
>> > > > > > > > >> My idea is simply to add the list of caches with the same
>> > > > > > distribution
>> > > > > > > > to
>> > > > > > > > >> the end of partition response. Client can use this
>> > information
>> > > > to
>> > > > > > > > populate
>> > > > > > > > >> partition info for more caches in a single request.
>> > > > > > > > >>
>> > > > > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <
>> > > [hidden email]>
>> > > > > > > wrote:
>> > > > > > > > >>
>> > > > > > > > >> > Vladimir,
>> > > > > > > > >> >
>> > > > > > > > >> > So correct me if I'm wrong, what you propose is to
>> avoid
>> > > > > > mentioning
>> > > > > > > > >> > of cache groups, and use instead of "cache group" term
>> > > > something
>> > > > > > > like
>> > > > > > > > >> > "distribution"? Or do you propose some changes in
>> > protocol?
>> > > If
>> > > > > so,
>> > > > > > > can
>> > > > > > > > >> > you briefly explain, what kind of changes they are?
>> > > > > > > > >> >
>> > > > > > > > >> > Best Regards,
>> > > > > > > > >> > Igor
>> > > > > > > > >> >
>> > > > > > > > >> >
>> > > > > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
>> > > > > > > [hidden email]>
>> > > > > > > > >> > wrote:
>> > > > > > > > >> >
>> > > > > > > > >> > > Igor,
>> > > > > > > > >> > >
>> > > > > > > > >> > > Yes, cache groups are public API. However, we try to
>> > avoid
>> > > > new
>> > > > > > > APIs
>> > > > > > > > >> > > depending on them.
>> > > > > > > > >> > > The main point from my side is that “similar cache
>> > group”
>> > > > can
>> > > > > be
>> > > > > > > > >> easily
>> > > > > > > > >> > > generalized to “similar distribution”. This way we
>> avoid
>> > > > cache
>> > > > > > > > groups
>> > > > > > > > >> on
>> > > > > > > > >> > > protocol level at virtually no cost.
>> > > > > > > > >> > >
>> > > > > > > > >> > > Vladimir.
>> > > > > > > > >> > >
>> > > > > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <
>> > > > [hidden email]
>> > > > > >:
>> > > > > > > > >> > >
>> > > > > > > > >> > > > Guys,
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > Can you explain why do we want to avoid Cache
>> groups
>> > in
>> > > > > > > protocol?
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > If it's about simplicity of the protocol, then
>> > removing
>> > > > > cache
>> > > > > > > > groups
>> > > > > > > > >> > will
>> > > > > > > > >> > > > not help much with it - we will still need to
>> include
>> > > > > > > > >> "knownCacheIds"
>> > > > > > > > >> > > > field in request and
>> "cachesWithTheSamePartitioning"
>> > > field
>> > > > > in
>> > > > > > > > >> response.
>> > > > > > > > >> > > > And also, since when do Ignite prefers simplicity
>> over
>> > > > > > > > performance?
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > If it's about not wanting to show internals of
>> Ignite
>> > > then
>> > > > > it
>> > > > > > > > sounds
>> > > > > > > > >> > like
>> > > > > > > > >> > > > a very weak argument to me, since Cache Groups is a
>> > > public
>> > > > > > thing
>> > > > > > > > >> [1].
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > [1] -
>> > https://apacheignite.readme.io/docs/cache-groups
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > Best Regards,
>> > > > > > > > >> > > > Igor
>> > > > > > > > >> > > >
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
>> > > > > > > > >> [hidden email]>
>> > > > > > > > >> > > > wrote:
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > > Pavel, Igor,
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > This is not very accurate to say that this will
>> not
>> > > save
>> > > > > > > memory.
>> > > > > > > > >> In
>> > > > > > > > >> > > > > practice we observed a number of OOME issues on
>> the
>> > > > > > > server-side
>> > > > > > > > >> due
>> > > > > > > > >> > to
>> > > > > > > > >> > > > many
>> > > > > > > > >> > > > > caches and it was one of motivations for cache
>> > groups
>> > > > > > (another
>> > > > > > > > one
>> > > > > > > > >> > disk
>> > > > > > > > >> > > > > access optimizations). On the other hand, I agree
>> > that
>> > > > > we'd
>> > > > > > > > >> better to
>> > > > > > > > >> > > > avoid
>> > > > > > > > >> > > > > cache groups in the protocol because this is
>> > internal
>> > > > > > > > >> implementation
>> > > > > > > > >> > > > detail
>> > > > > > > > >> > > > > which is likely (I hope so) to be changed in
>> future.
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > So I have another proposal - let's track caches
>> with
>> > > the
>> > > > > > same
>> > > > > > > > >> > affinity
>> > > > > > > > >> > > > > distribution instead. That is, normally most of
>> > > > > PARTITIONED
>> > > > > > > > caches
>> > > > > > > > >> > will
>> > > > > > > > >> > > > > have very few variants of configuration: it will
>> be
>> > > > > > Rendezvous
>> > > > > > > > >> > affinity
>> > > > > > > > >> > > > > function, most likely with default partition
>> number
>> > > and
>> > > > > with
>> > > > > > > 1-2
>> > > > > > > > >> > > backups
>> > > > > > > > >> > > > at
>> > > > > > > > >> > > > > most. So when affinity distribution for specific
>> > cache
>> > > > is
>> > > > > > > > >> requested,
>> > > > > > > > >> > we
>> > > > > > > > >> > > > can
>> > > > > > > > >> > > > > append to the response *list of caches with the
>> same
>> > > > > > > > >> distribution*.
>> > > > > > > > >> > > I.e.:
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > class AffinityResponse {
>> > > > > > > > >> > > > >     Object distribution;    // Actual
>> distribution
>> > > > > > > > >> > > > >     List<Integer> cacheIds; // Caches with
>> similar
>> > > > > > > distribution
>> > > > > > > > >> > > > > }
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > Makes sense?
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
>> > > > > > > > >> [hidden email]>
>> > > > > > > > >> > > > > wrote:
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > > Igor, I have a feeling that we should omit
>> Cache
>> > > Group
>> > > > > > stuff
>> > > > > > > > >> from
>> > > > > > > > >> > the
>> > > > > > > > >> > > > > > protocol.
>> > > > > > > > >> > > > > > It is a rare use case and even then dealing
>> with
>> > > them
>> > > > on
>> > > > > > > > client
>> > > > > > > > >> > > barely
>> > > > > > > > >> > > > > > saves some memory.
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > We can keep it simple and have partition map
>> per
>> > > > > cacheId.
>> > > > > > > > >> Thoughts?
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
>> > > > > > > > [hidden email]>
>> > > > > > > > >> > > wrote:
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > > Guys, I've updated the proposal once again
>> [1],
>> > so
>> > > > > > 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <
>> > > > > > > > >> [hidden email]>
>> > > > > > > > >> > > > > wrote:
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > > > > 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.
>> > > > > > > > >> > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > > >> > > > >
>> > > > > > > > >> > > > > > > >> > > >
>> > > > > > > > >> > > > > > > >> > >
>> > > > > > > > >> > > > > > > >> >
>> > > > > > > > >> > > > > > > >>
>> > > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > >
>> > > > > > > > >> > >
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

[Pavel Tupitsyn]

Default value for boolean is false, and I though we'll have the feature
enabled by default.
But I agree with you. Let's disable by default and name the config property
EnableAffinityAwareness.

On Wed, Mar 13, 2019 at 12:52 PM Igor Sapego <[hidden email]> wrote:

> For the "false" I mean "disable" here.
>
> BTW, I believe we should name this parameter in a positive way:
> EnableAffinityAwareness, not disable.
>
> Best Regards,
> Igor
>
>
> On Wed, Mar 13, 2019 at 12:50 PM Igor Sapego <[hidden email]> wrote:
>
> > Well, yes, this looks like a simplest solution. Let's implement it for
> the
> > beginning and set this feature to "false" by default, as this feature
> looks
> > complex, probably error-prone, and should be considered in a "beta"
> > state for the first release.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Mar 11, 2019 at 8:04 PM Pavel Tupitsyn <[hidden email]>
> > wrote:
> >
> >> My suggestion is a boolean flag in client configuration:
> >> DisableAffinityAwareness
> >> And use old random/round-robin behavior with only one active connection.
> >>
> >> On Mon, Mar 11, 2019 at 1:36 PM Igor Sapego <[hidden email]> wrote:
> >>
> >> > Pavel,
> >> >
> >> > That's right. Do you have other suggestions or objections?
> >> >
> >> > Best Regards,
> >> > Igor
> >> >
> >> >
> >> > On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn <[hidden email]>
> >> > wrote:
> >> >
> >> > > >  maxConnectionNumber parameter
> >> > > What's the idea? Follow the Best Effor Affinity logic, but establish
> >> up
> >> > to
> >> > > N connections?
> >> > >
> >> > > On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego <[hidden email]>
> >> wrote:
> >> > >
> >> > > > I can propose two improvements here:
> >> > > >
> >> > > > 1. A simple one. Lets introduce maxConnectionNumber parameter
> >> > > > in ClientConfiguration. As it is easy to implement it may be
> >> introduced
> >> > > > together with the new feature to give user an additional control.
> >> > > >
> >> > > > 2. Asynchronous connection establishment. In this case startup
> >> method
> >> > > > of a client returns control to user once it have established at
> >> least
> >> > one
> >> > > > connection. Other connections established in background by a
> >> separate
> >> > > > thread. This one is harder to implement and maybe it makes sense
> to
> >> add
> >> > > > it as a separate feature.
> >> > > >
> >> > > > Best Regards,
> >> > > > Igor
> >> > > >
> >> > > >
> >> > > > On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <
> [hidden email]
> >> >
> >> > > > wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > I'm in progress of implementing this IEP for Ignite.NET, and I
> >> have
> >> > > > > concerns about the following:
> >> > > > >
> >> > > > > > On thin client startup it connects to all nodes provided by
> >> client
> >> > > > > configuration
> >> > > > >
> >> > > > > Should we, at least, make this behavior optional?
> >> > > > >
> >> > > > > One of the benefits of thin client is quick startup/connect time
> >> and
> >> > > low
> >> > > > > resource usage.
> >> > > > > Adding "connect all" behavior can negate those benefits,
> >> especially
> >> > on
> >> > > > > large clusters.
> >> > > > >
> >> > > > > Thoughts?
> >> > > > >
> >> > > > > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <[hidden email]
> >
> >> > > wrote:
> >> > > > >
> >> > > > > > Guys, I've updated the IEP page [1] once again.
> >> > > > > >
> >> > > > > > Please, pay attention to sections Cache affinity mapping
> >> acquiring
> >> > > > > > (4.a, format of Cache Partitions Request) and Changes to cache
> >> > > > > > operations with single key (3 and 4, algorithm).
> >> > > > > >
> >> > > > > > Long story short, I've decided to add some additional data to
> >> Cache
> >> > > > > > Partitions Response, so that client can determine how to
> >> calculate
> >> > > > > > partition for a given key properly.
> >> > > > > >
> >> > > > > > [1] -
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> >> > > > > >
> >> > > > > > Best Regards,
> >> > > > > > Igor
> >> > > > > >
> >> > > > > >
> >> > > > > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <
> >> > [hidden email]>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Looks good to me.
> >> > > > > > >
> >> > > > > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <
> >> [hidden email]>
> >> > > > wrote:
> >> > > > > > >
> >> > > > > > > > I've updated IEP page: [1]
> >> > > > > > > >
> >> > > > > > > > What do you think now? To me it looks cleaner.
> >> > > > > > > >
> >> > > > > > > > [1] -
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> >> > > > > > > >
> >> > > > > > > > Best Regards,
> >> > > > > > > > Igor
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <
> >> [hidden email]
> >> > >
> >> > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Ok, I understand now. I'll try updating IEP according to
> >> this
> >> > > > > > proposal
> >> > > > > > > > and
> >> > > > > > > > > notify you guys.
> >> > > > > > > > >
> >> > > > > > > > > Best Regards,
> >> > > > > > > > > Igor
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
> >> > > > > [hidden email]
> >> > > > > > >
> >> > > > > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > >> Igor,
> >> > > > > > > > >>
> >> > > > > > > > >> My idea is simply to add the list of caches with the
> same
> >> > > > > > distribution
> >> > > > > > > > to
> >> > > > > > > > >> the end of partition response. Client can use this
> >> > information
> >> > > > to
> >> > > > > > > > populate
> >> > > > > > > > >> partition info for more caches in a single request.
> >> > > > > > > > >>
> >> > > > > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <
> >> > > [hidden email]>
> >> > > > > > > wrote:
> >> > > > > > > > >>
> >> > > > > > > > >> > Vladimir,
> >> > > > > > > > >> >
> >> > > > > > > > >> > So correct me if I'm wrong, what you propose is to
> >> avoid
> >> > > > > > mentioning
> >> > > > > > > > >> > of cache groups, and use instead of "cache group"
> term
> >> > > > something
> >> > > > > > > like
> >> > > > > > > > >> > "distribution"? Or do you propose some changes in
> >> > protocol?
> >> > > If
> >> > > > > so,
> >> > > > > > > can
> >> > > > > > > > >> > you briefly explain, what kind of changes they are?
> >> > > > > > > > >> >
> >> > > > > > > > >> > Best Regards,
> >> > > > > > > > >> > Igor
> >> > > > > > > > >> >
> >> > > > > > > > >> >
> >> > > > > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> >> > > > > > > [hidden email]>
> >> > > > > > > > >> > wrote:
> >> > > > > > > > >> >
> >> > > > > > > > >> > > Igor,
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > Yes, cache groups are public API. However, we try
> to
> >> > avoid
> >> > > > new
> >> > > > > > > APIs
> >> > > > > > > > >> > > depending on them.
> >> > > > > > > > >> > > The main point from my side is that “similar cache
> >> > group”
> >> > > > can
> >> > > > > be
> >> > > > > > > > >> easily
> >> > > > > > > > >> > > generalized to “similar distribution”. This way we
> >> avoid
> >> > > > cache
> >> > > > > > > > groups
> >> > > > > > > > >> on
> >> > > > > > > > >> > > protocol level at virtually no cost.
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > Vladimir.
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <
> >> > > > [hidden email]
> >> > > > > >:
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > > Guys,
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > Can you explain why do we want to avoid Cache
> >> groups
> >> > in
> >> > > > > > > protocol?
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > If it's about simplicity of the protocol, then
> >> > removing
> >> > > > > cache
> >> > > > > > > > groups
> >> > > > > > > > >> > will
> >> > > > > > > > >> > > > not help much with it - we will still need to
> >> include
> >> > > > > > > > >> "knownCacheIds"
> >> > > > > > > > >> > > > field in request and
> >> "cachesWithTheSamePartitioning"
> >> > > field
> >> > > > > in
> >> > > > > > > > >> response.
> >> > > > > > > > >> > > > And also, since when do Ignite prefers simplicity
> >> over
> >> > > > > > > > performance?
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > If it's about not wanting to show internals of
> >> Ignite
> >> > > then
> >> > > > > it
> >> > > > > > > > sounds
> >> > > > > > > > >> > like
> >> > > > > > > > >> > > > a very weak argument to me, since Cache Groups
> is a
> >> > > public
> >> > > > > > thing
> >> > > > > > > > >> [1].
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > [1] -
> >> > https://apacheignite.readme.io/docs/cache-groups
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > Best Regards,
> >> > > > > > > > >> > > > Igor
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir Ozerov <
> >> > > > > > > > >> [hidden email]>
> >> > > > > > > > >> > > > wrote:
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > > Pavel, Igor,
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > This is not very accurate to say that this will
> >> not
> >> > > save
> >> > > > > > > memory.
> >> > > > > > > > >> In
> >> > > > > > > > >> > > > > practice we observed a number of OOME issues on
> >> the
> >> > > > > > > server-side
> >> > > > > > > > >> due
> >> > > > > > > > >> > to
> >> > > > > > > > >> > > > many
> >> > > > > > > > >> > > > > caches and it was one of motivations for cache
> >> > groups
> >> > > > > > (another
> >> > > > > > > > one
> >> > > > > > > > >> > disk
> >> > > > > > > > >> > > > > access optimizations). On the other hand, I
> agree
> >> > that
> >> > > > > we'd
> >> > > > > > > > >> better to
> >> > > > > > > > >> > > > avoid
> >> > > > > > > > >> > > > > cache groups in the protocol because this is
> >> > internal
> >> > > > > > > > >> implementation
> >> > > > > > > > >> > > > detail
> >> > > > > > > > >> > > > > which is likely (I hope so) to be changed in
> >> future.
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > So I have another proposal - let's track caches
> >> with
> >> > > the
> >> > > > > > same
> >> > > > > > > > >> > affinity
> >> > > > > > > > >> > > > > distribution instead. That is, normally most of
> >> > > > > PARTITIONED
> >> > > > > > > > caches
> >> > > > > > > > >> > will
> >> > > > > > > > >> > > > > have very few variants of configuration: it
> will
> >> be
> >> > > > > > Rendezvous
> >> > > > > > > > >> > affinity
> >> > > > > > > > >> > > > > function, most likely with default partition
> >> number
> >> > > and
> >> > > > > with
> >> > > > > > > 1-2
> >> > > > > > > > >> > > backups
> >> > > > > > > > >> > > > at
> >> > > > > > > > >> > > > > most. So when affinity distribution for
> specific
> >> > cache
> >> > > > is
> >> > > > > > > > >> requested,
> >> > > > > > > > >> > we
> >> > > > > > > > >> > > > can
> >> > > > > > > > >> > > > > append to the response *list of caches with the
> >> same
> >> > > > > > > > >> distribution*.
> >> > > > > > > > >> > > I.e.:
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > class AffinityResponse {
> >> > > > > > > > >> > > > >     Object distribution;    // Actual
> >> distribution
> >> > > > > > > > >> > > > >     List<Integer> cacheIds; // Caches with
> >> similar
> >> > > > > > > distribution
> >> > > > > > > > >> > > > > }
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > Makes sense?
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel Tupitsyn <
> >> > > > > > > > >> [hidden email]>
> >> > > > > > > > >> > > > > wrote:
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > > Igor, I have a feeling that we should omit
> >> Cache
> >> > > Group
> >> > > > > > stuff
> >> > > > > > > > >> from
> >> > > > > > > > >> > the
> >> > > > > > > > >> > > > > > protocol.
> >> > > > > > > > >> > > > > > It is a rare use case and even then dealing
> >> with
> >> > > them
> >> > > > on
> >> > > > > > > > client
> >> > > > > > > > >> > > barely
> >> > > > > > > > >> > > > > > saves some memory.
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > We can keep it simple and have partition map
> >> per
> >> > > > > cacheId.
> >> > > > > > > > >> Thoughts?
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <
> >> > > > > > > > [hidden email]>
> >> > > > > > > > >> > > wrote:
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > > Guys, I've updated the proposal once again
> >> [1],
> >> > so
> >> > > > > > 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 Thu, Jan 17, 2019 at 1:05 PM Igor
> Sapego <
> >> > > > > > > > >> [hidden email]>
> >> > > > > > > > >> > > > > wrote:
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > > > > 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.
> >> > > > > > > > >> > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > > >> > > > >
> >> > > > > > > > >> > > > > > > >> > > >
> >> > > > > > > > >> > > > > > > >> > >
> >> > > > > > > > >> > > > > > > >> >
> >> > > > > > > > >> > > > > > > >>
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > >
> >> > > > > > > > >> >
> >> > > > > > > > >>
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

[Alexey Plekhanov]

Hello guys,


I've implemented affinity awareness support for java thin client [1]. There
is only client-side affected by the patch. Can anyone review the change?


1: https://issues.apache.org/jira/browse/IGNITE-11898



ср, 13 мар. 2019 г. в 22:54, Pavel Tupitsyn <[hidden email]>:

> Default value for boolean is false, and I though we'll have the feature
> enabled by default.
> But I agree with you. Let's disable by default and name the config property
> EnableAffinityAwareness.
>
> On Wed, Mar 13, 2019 at 12:52 PM Igor Sapego <[hidden email]> wrote:
>
> > For the "false" I mean "disable" here.
> >
> > BTW, I believe we should name this parameter in a positive way:
> > EnableAffinityAwareness, not disable.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Wed, Mar 13, 2019 at 12:50 PM Igor Sapego <[hidden email]> wrote:
> >
> > > Well, yes, this looks like a simplest solution. Let's implement it for
> > the
> > > beginning and set this feature to "false" by default, as this feature
> > looks
> > > complex, probably error-prone, and should be considered in a "beta"
> > > state for the first release.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Mar 11, 2019 at 8:04 PM Pavel Tupitsyn <[hidden email]>
> > > wrote:
> > >
> > >> My suggestion is a boolean flag in client configuration:
> > >> DisableAffinityAwareness
> > >> And use old random/round-robin behavior with only one active
> connection.
> > >>
> > >> On Mon, Mar 11, 2019 at 1:36 PM Igor Sapego <[hidden email]>
> wrote:
> > >>
> > >> > Pavel,
> > >> >
> > >> > That's right. Do you have other suggestions or objections?
> > >> >
> > >> > Best Regards,
> > >> > Igor
> > >> >
> > >> >
> > >> > On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn <
> [hidden email]>
> > >> > wrote:
> > >> >
> > >> > > >  maxConnectionNumber parameter
> > >> > > What's the idea? Follow the Best Effor Affinity logic, but
> establish
> > >> up
> > >> > to
> > >> > > N connections?
> > >> > >
> > >> > > On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego <[hidden email]>
> > >> wrote:
> > >> > >
> > >> > > > I can propose two improvements here:
> > >> > > >
> > >> > > > 1. A simple one. Lets introduce maxConnectionNumber parameter
> > >> > > > in ClientConfiguration. As it is easy to implement it may be
> > >> introduced
> > >> > > > together with the new feature to give user an additional
> control.
> > >> > > >
> > >> > > > 2. Asynchronous connection establishment. In this case startup
> > >> method
> > >> > > > of a client returns control to user once it have established at
> > >> least
> > >> > one
> > >> > > > connection. Other connections established in background by a
> > >> separate
> > >> > > > thread. This one is harder to implement and maybe it makes sense
> > to
> > >> add
> > >> > > > it as a separate feature.
> > >> > > >
> > >> > > > Best Regards,
> > >> > > > Igor
> > >> > > >
> > >> > > >
> > >> > > > On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn <
> > [hidden email]
> > >> >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > I'm in progress of implementing this IEP for Ignite.NET, and I
> > >> have
> > >> > > > > concerns about the following:
> > >> > > > >
> > >> > > > > > On thin client startup it connects to all nodes provided by
> > >> client
> > >> > > > > configuration
> > >> > > > >
> > >> > > > > Should we, at least, make this behavior optional?
> > >> > > > >
> > >> > > > > One of the benefits of thin client is quick startup/connect
> time
> > >> and
> > >> > > low
> > >> > > > > resource usage.
> > >> > > > > Adding "connect all" behavior can negate those benefits,
> > >> especially
> > >> > on
> > >> > > > > large clusters.
> > >> > > > >
> > >> > > > > Thoughts?
> > >> > > > >
> > >> > > > > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego <
> [hidden email]
> > >
> > >> > > wrote:
> > >> > > > >
> > >> > > > > > Guys, I've updated the IEP page [1] once again.
> > >> > > > > >
> > >> > > > > > Please, pay attention to sections Cache affinity mapping
> > >> acquiring
> > >> > > > > > (4.a, format of Cache Partitions Request) and Changes to
> cache
> > >> > > > > > operations with single key (3 and 4, algorithm).
> > >> > > > > >
> > >> > > > > > Long story short, I've decided to add some additional data
> to
> > >> Cache
> > >> > > > > > Partitions Response, so that client can determine how to
> > >> calculate
> > >> > > > > > partition for a given key properly.
> > >> > > > > >
> > >> > > > > > [1] -
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > >> > > > > >
> > >> > > > > > Best Regards,
> > >> > > > > > Igor
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn <
> > >> > [hidden email]>
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > Looks good to me.
> > >> > > > > > >
> > >> > > > > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <
> > >> [hidden email]>
> > >> > > > wrote:
> > >> > > > > > >
> > >> > > > > > > > I've updated IEP page: [1]
> > >> > > > > > > >
> > >> > > > > > > > What do you think now? To me it looks cleaner.
> > >> > > > > > > >
> > >> > > > > > > > [1] -
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
> > >> > > > > > > >
> > >> > > > > > > > Best Regards,
> > >> > > > > > > > Igor
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego <
> > >> [hidden email]
> > >> > >
> > >> > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > > Ok, I understand now. I'll try updating IEP according
> to
> > >> this
> > >> > > > > > proposal
> > >> > > > > > > > and
> > >> > > > > > > > > notify you guys.
> > >> > > > > > > > >
> > >> > > > > > > > > Best Regards,
> > >> > > > > > > > > Igor
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov <
> > >> > > > > [hidden email]
> > >> > > > > > >
> > >> > > > > > > > > wrote:
> > >> > > > > > > > >
> > >> > > > > > > > >> Igor,
> > >> > > > > > > > >>
> > >> > > > > > > > >> My idea is simply to add the list of caches with the
> > same
> > >> > > > > > distribution
> > >> > > > > > > > to
> > >> > > > > > > > >> the end of partition response. Client can use this
> > >> > information
> > >> > > > to
> > >> > > > > > > > populate
> > >> > > > > > > > >> partition info for more caches in a single request.
> > >> > > > > > > > >>
> > >> > > > > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego <
> > >> > > [hidden email]>
> > >> > > > > > > wrote:
> > >> > > > > > > > >>
> > >> > > > > > > > >> > Vladimir,
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > So correct me if I'm wrong, what you propose is to
> > >> avoid
> > >> > > > > > mentioning
> > >> > > > > > > > >> > of cache groups, and use instead of "cache group"
> > term
> > >> > > > something
> > >> > > > > > > like
> > >> > > > > > > > >> > "distribution"? Or do you propose some changes in
> > >> > protocol?
> > >> > > If
> > >> > > > > so,
> > >> > > > > > > can
> > >> > > > > > > > >> > you briefly explain, what kind of changes they are?
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > Best Regards,
> > >> > > > > > > > >> > Igor
> > >> > > > > > > > >> >
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov <
> > >> > > > > > > [hidden email]>
> > >> > > > > > > > >> > wrote:
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > > Igor,
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > Yes, cache groups are public API. However, we try
> > to
> > >> > avoid
> > >> > > > new
> > >> > > > > > > APIs
> > >> > > > > > > > >> > > depending on them.
> > >> > > > > > > > >> > > The main point from my side is that “similar
> cache
> > >> > group”
> > >> > > > can
> > >> > > > > be
> > >> > > > > > > > >> easily
> > >> > > > > > > > >> > > generalized to “similar distribution”. This way
> we
> > >> avoid
> > >> > > > cache
> > >> > > > > > > > groups
> > >> > > > > > > > >> on
> > >> > > > > > > > >> > > protocol level at virtually no cost.
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > Vladimir.
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego <
> > >> > > > [hidden email]
> > >> > > > > >:
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > > Guys,
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > Can you explain why do we want to avoid Cache
> > >> groups
> > >> > in
> > >> > > > > > > protocol?
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > If it's about simplicity of the protocol, then
> > >> > removing
> > >> > > > > cache
> > >> > > > > > > > groups
> > >> > > > > > > > >> > will
> > >> > > > > > > > >> > > > not help much with it - we will still need to
> > >> include
> > >> > > > > > > > >> "knownCacheIds"
> > >> > > > > > > > >> > > > field in request and
> > >> "cachesWithTheSamePartitioning"
> > >> > > field
> > >> > > > > in
> > >> > > > > > > > >> response.
> > >> > > > > > > > >> > > > And also, since when do Ignite prefers
> simplicity
> > >> over
> > >> > > > > > > > performance?
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > If it's about not wanting to show internals of
> > >> Ignite
> > >> > > then
> > >> > > > > it
> > >> > > > > > > > sounds
> > >> > > > > > > > >> > like
> > >> > > > > > > > >> > > > a very weak argument to me, since Cache Groups
> > is a
> > >> > > public
> > >> > > > > > thing
> > >> > > > > > > > >> [1].
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > [1] -
> > >> > https://apacheignite.readme.io/docs/cache-groups
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > Best Regards,
> > >> > > > > > > > >> > > > Igor
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > On Mon, Feb 4, 2019 at 11:47 AM Vladimir
> Ozerov <
> > >> > > > > > > > >> [hidden email]>
> > >> > > > > > > > >> > > > wrote:
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > > Pavel, Igor,
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > This is not very accurate to say that this
> will
> > >> not
> > >> > > save
> > >> > > > > > > memory.
> > >> > > > > > > > >> In
> > >> > > > > > > > >> > > > > practice we observed a number of OOME issues
> on
> > >> the
> > >> > > > > > > server-side
> > >> > > > > > > > >> due
> > >> > > > > > > > >> > to
> > >> > > > > > > > >> > > > many
> > >> > > > > > > > >> > > > > caches and it was one of motivations for
> cache
> > >> > groups
> > >> > > > > > (another
> > >> > > > > > > > one
> > >> > > > > > > > >> > disk
> > >> > > > > > > > >> > > > > access optimizations). On the other hand, I
> > agree
> > >> > that
> > >> > > > > we'd
> > >> > > > > > > > >> better to
> > >> > > > > > > > >> > > > avoid
> > >> > > > > > > > >> > > > > cache groups in the protocol because this is
> > >> > internal
> > >> > > > > > > > >> implementation
> > >> > > > > > > > >> > > > detail
> > >> > > > > > > > >> > > > > which is likely (I hope so) to be changed in
> > >> future.
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > So I have another proposal - let's track
> caches
> > >> with
> > >> > > the
> > >> > > > > > same
> > >> > > > > > > > >> > affinity
> > >> > > > > > > > >> > > > > distribution instead. That is, normally most
> of
> > >> > > > > PARTITIONED
> > >> > > > > > > > caches
> > >> > > > > > > > >> > will
> > >> > > > > > > > >> > > > > have very few variants of configuration: it
> > will
> > >> be
> > >> > > > > > Rendezvous
> > >> > > > > > > > >> > affinity
> > >> > > > > > > > >> > > > > function, most likely with default partition
> > >> number
> > >> > > and
> > >> > > > > with
> > >> > > > > > > 1-2
> > >> > > > > > > > >> > > backups
> > >> > > > > > > > >> > > > at
> > >> > > > > > > > >> > > > > most. So when affinity distribution for
> > specific
> > >> > cache
> > >> > > > is
> > >> > > > > > > > >> requested,
> > >> > > > > > > > >> > we
> > >> > > > > > > > >> > > > can
> > >> > > > > > > > >> > > > > append to the response *list of caches with
> the
> > >> same
> > >> > > > > > > > >> distribution*.
> > >> > > > > > > > >> > > I.e.:
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > class AffinityResponse {
> > >> > > > > > > > >> > > > >     Object distribution;    // Actual
> > >> distribution
> > >> > > > > > > > >> > > > >     List<Integer> cacheIds; // Caches with
> > >> similar
> > >> > > > > > > distribution
> > >> > > > > > > > >> > > > > }
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > Makes sense?
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > On Sun, Feb 3, 2019 at 8:31 PM Pavel
> Tupitsyn <
> > >> > > > > > > > >> [hidden email]>
> > >> > > > > > > > >> > > > > wrote:
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > > Igor, I have a feeling that we should omit
> > >> Cache
> > >> > > Group
> > >> > > > > > stuff
> > >> > > > > > > > >> from
> > >> > > > > > > > >> > the
> > >> > > > > > > > >> > > > > > protocol.
> > >> > > > > > > > >> > > > > > It is a rare use case and even then dealing
> > >> with
> > >> > > them
> > >> > > > on
> > >> > > > > > > > client
> > >> > > > > > > > >> > > barely
> > >> > > > > > > > >> > > > > > saves some memory.
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > We can keep it simple and have partition
> map
> > >> per
> > >> > > > > cacheId.
> > >> > > > > > > > >> Thoughts?
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego
> <
> > >> > > > > > > > [hidden email]>
> > >> > > > > > > > >> > > wrote:
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > > Guys, I've updated the proposal once
> again
> > >> [1],
> > >> > so
> > >> > > > > > 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 Thu, Jan 17, 2019 at 1:05 PM Igor
> > Sapego <
> > >> > > > > > > > >> [hidden email]>
> > >> > > > > > > > >> > > > > wrote:
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > > > > 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.
> > >> > > > > > > > >> > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > > > >> > > >
> > >> > > > > > > > >> > > > > > > >> > >
> > >> > > > > > > > >> > > > > > > >> >
> > >> > > > > > > > >> > > > > > > >>
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> >
> > >> > > > > > > > >>
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>