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
>
