ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Best Effort Affinity for thin clients
Date Sun, 03 Feb 2019 17:31:05 GMT
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