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 Mon, 11 Mar 2019 17:04:03 GMT
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 <isapego@apache.org> 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 <ptupitsyn@apache.org>
> 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 <isapego@apache.org> 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 <ptupitsyn@apache.org>
> > > 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 <isapego@apache.org>
> > 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 <
> 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