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
