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 <ptupit...@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 <isap...@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 <plehanov.a...@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 <ptupit...@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 <ptupit...@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 <isap...@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 < >> ptupit...@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 <dma...@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 < >> > > ptupit...@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 >> > > >> > > > >> > > >> > > >> > > >> > >> > > >> >> > > > >> > > >> > >> >
