You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Pavel Tupitsyn <pt...@apache.org> on 2020/05/06 14:30:47 UTC
Re: IEP-44 Thin Client Discovery
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 <pt...@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 <is...@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 <pt...@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 <dm...@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 <pt...@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
>> > > >
>> > >
>> >
>>
>
Re: IEP-44 Thin Client Discovery
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <pt...@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 <pt...@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 <is...@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 <pt...@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 <dm...@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
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: IEP-44 Thin Client Discovery
Posted by Pavel Tupitsyn <pt...@apache.org>.
Igniters, the feature is ready for review:
https://issues.apache.org/jira/browse/IGNITE-12932
https://github.com/apache/ignite/pull/7744
On Thu, May 7, 2020 at 6:23 PM Pavel Tupitsyn <pt...@apache.org> wrote:
> Alex,
>
> Event subscription is a good idea. We should certainly add this in future.
> However, it might be non-trivial with multiple connections: should we
> subscribe on every server?
> Then we'll get an event from every server, which seems redundant.
>
> Igor,
>
> Agreed. Let's keep existing behavior.
>
> On Thu, May 7, 2020 at 5:29 PM Igor Sapego <is...@apache.org> wrote:
>
>> Pavel,
>>
>> First of all, I think we need to move it out of scope of this feature.
>>
>> Also, why do we need to keep connection alive? I think, if user do not
>> use connection for a long time and connection is lost we could just
>> detect this and re-establish connection on the next user action which
>> requires network interaction. Any issues with this approach?
>>
>> Best Regards,
>> Igor
>>
>>
>> On Thu, May 7, 2020 at 1:18 AM Alex Plehanov <pl...@gmail.com>
>> wrote:
>>
>> > Pavel,
>> >
>> > Since we have a notification mechanism for thin clients now, we can
>> > implement a subscription to some types of events and this can be used
>> > to inform a client about topology change as well. I think it's a
>> > more appropriate way to detect topology changes than ping requests. But
>> > approach with ping requests has another advantage: the client can detect
>> > that connection was lost earlier. With subscriptions approach client
>> will
>> > detect problems with a connection only after the next request to the
>> > server.
>> >
>> >
>> > ср, 6 мая 2020 г. в 17:31, Pavel Tupitsyn <pt...@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 <pt...@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 <is...@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 <dm...@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
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: IEP-44 Thin Client Discovery
Posted by Pavel Tupitsyn <pt...@apache.org>.
Alex,
Event subscription is a good idea. We should certainly add this in future.
However, it might be non-trivial with multiple connections: should we
subscribe on every server?
Then we'll get an event from every server, which seems redundant.
Igor,
Agreed. Let's keep existing behavior.
On Thu, May 7, 2020 at 5:29 PM Igor Sapego <is...@apache.org> wrote:
> Pavel,
>
> First of all, I think we need to move it out of scope of this feature.
>
> Also, why do we need to keep connection alive? I think, if user do not
> use connection for a long time and connection is lost we could just
> detect this and re-establish connection on the next user action which
> requires network interaction. Any issues with this approach?
>
> Best Regards,
> Igor
>
>
> On Thu, May 7, 2020 at 1:18 AM Alex Plehanov <pl...@gmail.com>
> wrote:
>
> > Pavel,
> >
> > Since we have a notification mechanism for thin clients now, we can
> > implement a subscription to some types of events and this can be used
> > to inform a client about topology change as well. I think it's a
> > more appropriate way to detect topology changes than ping requests. But
> > approach with ping requests has another advantage: the client can detect
> > that connection was lost earlier. With subscriptions approach client will
> > detect problems with a connection only after the next request to the
> > server.
> >
> >
> > ср, 6 мая 2020 г. в 17:31, Pavel Tupitsyn <pt...@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 <pt...@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 <is...@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 <dm...@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
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: IEP-44 Thin Client Discovery
Posted by Igor Sapego <is...@apache.org>.
Pavel,
First of all, I think we need to move it out of scope of this feature.
Also, why do we need to keep connection alive? I think, if user do not
use connection for a long time and connection is lost we could just
detect this and re-establish connection on the next user action which
requires network interaction. Any issues with this approach?
Best Regards,
Igor
On Thu, May 7, 2020 at 1:18 AM Alex Plehanov <pl...@gmail.com>
wrote:
> Pavel,
>
> Since we have a notification mechanism for thin clients now, we can
> implement a subscription to some types of events and this can be used
> to inform a client about topology change as well. I think it's a
> more appropriate way to detect topology changes than ping requests. But
> approach with ping requests has another advantage: the client can detect
> that connection was lost earlier. With subscriptions approach client will
> detect problems with a connection only after the next request to the
> server.
>
>
> ср, 6 мая 2020 г. в 17:31, Pavel Tupitsyn <pt...@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 <pt...@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 <is...@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 <dm...@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
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: IEP-44 Thin Client Discovery
Posted by Alex Plehanov <pl...@gmail.com>.
Pavel,
Since we have a notification mechanism for thin clients now, we can
implement a subscription to some types of events and this can be used
to inform a client about topology change as well. I think it's a
more appropriate way to detect topology changes than ping requests. But
approach with ping requests has another advantage: the client can detect
that connection was lost earlier. With subscriptions approach client will
detect problems with a connection only after the next request to the server.
ср, 6 мая 2020 г. в 17:31, Pavel Tupitsyn <pt...@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 <pt...@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 <is...@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 <pt...@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 <dm...@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
> >> > > >
> >> > >
> >> >
> >>
> >
>