Alex, I agree with your proposal. It is ok to start scanning servers firstly using the same default port, then continue with subsequent ports within range.
пт, 20 янв. 2023 г. в 10:47, Alex Plehanov <plehanov.a...@gmail.com>: > Pavel, > > But in this case connections still will be unbalanced for disabled > partition awareness. What if we add some kind of heuristic for choosing the > first channel, for example, sort addresses by port and select random from > the set of addresses with the same (minimal) port? This will cover most of > the production cases, since several nodes on the same host can mostly be > found in test environments. > > пт, 20 янв. 2023 г. в 09:43, Pavel Tupitsyn <ptupit...@apache.org>: > > > Alex, I agree with proposals 2 and 3. > > > > However, IGNITE-15807 is not about random server, it is about random port > > on the same server. > > As I understand, the scenario is: we know that the server is at address > > a.b.c.d, > > but we are not sure which port will be chosen, > > because ClientConnectorConfiguration has a portRange. > > Most likely it is the first port in range, so we should try that first. > > > > On Thu, Jan 19, 2023 at 9:36 PM Alex Plehanov <plehanov.a...@gmail.com> > > wrote: > > > > > Hello, Igniters! > > > > > > I've found that since Ignite 2.12 java thin client always connects to > the > > > first address from the provided addresses list. In typical > configuration > > > this leads to overloading one server node and underloading other server > > > nodes. Even when partition awareness is enabled some types of > operations > > > still use default connection. This behaviour was introduced by [1]. > > Before > > > this patch default channel was chosen randomly. > > > I've read comments in the ticket, but I'm not sure I quite understand > the > > > described use case ("few nodes always exist, but other nodes are > > > added/removed based on the load") and how it was intended to be > resolved > > by > > > this fix. But certainly, it's not the best way to resolve this problem. > > > Perhaps, cluster discovery will be better for this case? We already > have > > it > > > in protocol and implementation for the .NET thin client, so it can be > > > implemented for the java thin client too. > > > > > > My proposals: > > > 1. Revert the patch (use random default node) > > > 2. Implement cluster discovery for java thin client > > > 3. If partition awareness is enabled - use random open channel instead > of > > > default channel for operation which can't be mapped to certain node (to > > > even better workload distribution to server nodes) > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-15807 > > > > > > -- Sincerely yours, Ivan Daschinskiy