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