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
