ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: IEP-44 Thin Client Discovery
Date Wed, 06 May 2020 14:30:47 GMT
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