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