ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: IEP-44 Thin Client Discovery
Date Thu, 07 May 2020 09:29:05 GMT
Hello!

I think it is OK if client loses cluster, in this case it should only check
the addresses with which it was configured to start.


Regards,
-- 
Ilya Kasnacheev


ср, 6 мая 2020 г. в 17:31, Pavel Tupitsyn <ptupitsyn@apache.org>:

> Igniters, let's discuss the following issue:
>
> For partition awareness, and now for cluster discovery, we use a response
> flag to detect topology changes.
> The problem is - if the client does not do anything (user code does not
> perform operations),
> then we'll never know about topology changes and may even lose the cluster
> (all known nodes leave).
>
> Should we introduce some keep-alive mechanism, so that thin clients send
> periodic ping requests?
> Maybe do this as a separate feature.
>
> Thoughts?
>
> On Tue, Apr 28, 2020 at 8:14 PM Pavel Tupitsyn <ptupitsyn@apache.org>
> wrote:
>
> > Ok, I've updated IEP and POC accordingly:
> > * Config flag removed
> > * IPs and host names retrieval simplified - use existing node properties
> > and attributes instead of Compute
> >
> > On Tue, Apr 28, 2020 at 7:57 PM Igor Sapego <isapego@apache.org> wrote:
> >
> >> I guess it makes sense. If anyone needs more control over connection
> >> we would need to implement a new feature anyway (like node filter we
> >> discussed earlier)
> >>
> >> Best Regards,
> >> Igor
> >>
> >>
> >> On Tue, Apr 28, 2020 at 12:29 PM Pavel Tupitsyn <ptupitsyn@apache.org>
> >> wrote:
> >>
> >> > > enable the capability if the best effort affinity is on
> >> > I agree, makes sense.
> >> >
> >> > Igor, what do you think?
> >> >
> >> > On Tue, Apr 28, 2020 at 8:25 AM Denis Magda <dmagda@apache.org>
> wrote:
> >> >
> >> > > Pavel,
> >> > >
> >> > > That would be a tremendous improvement for the recently release best
> >> > effort
> >> > > affinity feature. Without this capability, we force application
> >> > developers
> >> > > to reopen thin client connections every type a cluster is scaled
> out.
> >> I
> >> > > believe that once the folks start using the best effort affinity,
> >> we'll
> >> > be
> >> > > hearing more of a feature request for what you're proposing in this
> >> > thread.
> >> > > So, thanks for taking care of this proactively!
> >> > >
> >> > > As for the public API changes, do we really need any extra flag? I
> >> would
> >> > > enable the capability if the best effort affinity is on. For me,
> it's
> >> > just
> >> > > a natural improvement of the latter and it sounds reasonable to
> reuse
> >> the
> >> > > best effort affinity's flag.
> >> > >
> >> > > -
> >> > > Denis
> >> > >
> >> > >
> >> > > On Mon, Apr 27, 2020 at 2:58 AM Pavel Tupitsyn <
> ptupitsyn@apache.org>
> >> > > wrote:
> >> > >
> >> > > > Igniters,
> >> > > >
> >> > > > I've prepared an IEP [1] and a POC [2] for Thin Client Discovery
> >> > feature.
> >> > > > Let's discuss it here.
> >> > > >
> >> > > > In particular, I'd like to address the following points:
> >> > > >
> >> > > > 1. Value: do you think this would be a good feature to have?
> >> > > > 2. Public API changes: is a boolean property enough? Should we
> have
> >> > > > something more complex, so users can plug in custom logic to
> filter
> >> > > and/or
> >> > > > translate IPs and host names?
> >> > > > 3. Server-side implementation details: should we use Compute,
Node
> >> > > > Attributes, or something else to retrieve client endpoints from
> all
> >> > nodes
> >> > > > in cluster?
> >> > > >
> >> > > > [1]
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery
> >> > > > [2] https://github.com/apache/ignite/pull/7744
> >> > > > [3] https://issues.apache.org/jira/browse/IGNITE-12932
> >> > > >
> >> > >
> >> >
> >>
> >
>

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