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 >
