Re: [DISCUSSION] Java thin client connection balancing
Sounds good to me too.
On Fri, Jan 20, 2023 at 10:08 AM Ivan Daschinsky
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 :
>
> > 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 :
> >
> > > 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 >
> > > 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
>
Re: [DISCUSSION] Java thin client connection balancing
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 :
> 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 :
>
> > 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
> > 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
Re: [DISCUSSION] Java thin client connection balancing
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 :
> 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
> 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
> >
>
Re: [DISCUSSION] Java thin client connection balancing
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
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
>
