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 > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > >
