Sounds good to me too.
On Fri, Jan 20, 2023 at 10:08 AM Ivan Daschinsky <ivanda...@gmail.com>
wrote:
> 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
>
