ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sapego <isap...@apache.org>
Subject Re: Best Effort Affinity for thin clients
Date Thu, 14 Feb 2019 14:38:58 GMT
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 <ptupitsyn@apache.org> wrote:

> Looks good to me.
>
> On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego <isapego@apache.org> 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 <isapego@apache.org> 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 <vozerov@gridgain.com>
> > > 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 <isapego@apache.org>
> 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 <
> vozerov@gridgain.com>
> > >> > 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 <isapego@apache.org>:
> > >> > >
> > >> > > > 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 <
> > >> vozerov@gridgain.com>
> > >> > > > 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 <
> > >> ptupitsyn@apache.org>
> > >> > > > > 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 <
> > isapego@apache.org>
> > >> > > 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
<
> > >> isapego@apache.org>
> > >> > > > > wrote:
> > >> > > > > > >
> > >> > > > > > > > Yeah, I'll add it.
> > >> > > > > > > >
> > >> > > > > > > > Best Regards,
> > >> > > > > > > > Igor
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > On Wed, Jan 16, 2019 at 11:08 PM Pavel
Tupitsyn <
> > >> > > > > ptupitsyn@apache.org>
> > >> > > > > > > > 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 <
> > >> > isapego@apache.org
> > >> > > >
> > >> > > > > > 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 <
> > >> > > > > > ptupitsyn@apache.org
> > >> > > > > > > >
> > >> > > > > > > >> > 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 <
> > >> > > > isapego@apache.org
> > >> > > > > >
> > >> > > > > > > >> 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
> <
> > >> > > > > > > >> vozerov@gridgain.com
> > >> > > > > > > >> > >
> > >> > > > > > > >> > > > 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 <
> > >> > > > > > isapego@apache.org
> > >> > > > > > > >
> > >> > > > > > > >> > > 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
> > >> <
> > >> > > > > > > >> > > vozerov@gridgain.com
> > >> > > > > > > >> > > > >
> > >> > > > > > > >> > > > > > 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 <
> > >> > > > > > > >> > > > > > dsetrakyan@apache.org>
> > >> > > > > > > >> > > > > > > wrote:
> > >> > > > > > > >> > > > > > >
> > >> > > > > > > >> > > > > > > >
On Mon, Jun 18, 2018 at 11:07 AM, Denis
> > >> Magda <
> > >> > > > > > > >> > dmagda@apache.org
> > >> > > > > > > >> > > >
> > >> > > > > > > >> > > > > > 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.
> > >> > > > > > > >> > > > > > > >
> > >> > > > > > > >> > > > > > >
> > >> > > > > > > >> > > > > >
> > >> > > > > > > >> > > > >
> > >> > > > > > > >> > > >
> > >> > > > > > > >> > >
> > >> > > > > > > >> >
> > >> > > > > > > >>
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message