More load balancing policies #5157
Conversation
machine424
force-pushed
the
lb
branch
2 times, most recently
from
0717a44
to
ce378ba
Compare
src/test/java/io/vertx/core/loadbalancing/LoadBalancingTest.java
Outdated
Show resolved
Hide resolved
|
Please verify you have used the email associated to your Eclipse account and that you have signed-off your commit |
tsegismont
changed the title
|
I've changed the name of the PR because we'll use it to add all policies listed in #5154 |
I re-signed the ECA, maybe it needs some time to sync. |
adjust the Round Robin policy to handle a special case. Signed-off-by: machine424 <[email protected]>
| @@ -29,4 +29,6 @@ public interface Endpoint<E> { | |||
| */ | |||
| EndpointMetrics<?> metrics(); | |||
|
|
|||
|
|
|||
| public interface PreferenceAwareLoadBalancer { | ||
|
|
||
| /** | ||
| * TOO SIMPLE Hashing load balancer XXX. TODO |
There was a problem hiding this comment.
Would we need this or should we just implement consistent hashing?
(that will require re-implementing some wheels as I don't see any exisiting lib/utils for that)
There was a problem hiding this comment.
Honestly, I need to put more thought into this. As I see it, the problem is the following:
- we have for input either a value provided by the user or computed based on one or more request properties (e.g. client IP or, in the case of sticky sessions, the value of the session id).
- given an input value, we need to be able to stick to the same endpoint (even if other endpoints join or leave)
I'm not sure how to do this right now
| import static org.junit.Assert.assertEquals; | ||
|
|
||
| @RunWith(Parameterized.class) | ||
| public class PreferenceAwareLoadBalancingCornerCasesTest { |
There was a problem hiding this comment.
maybe we should merge this with LoadBalancingCornerCasesTest?
| * Select an endpoint among the provided list taking an attribute into account. | ||
| * | ||
| * @param endpoints the endpoint | ||
| * @param attribute the attribute TODO |
There was a problem hiding this comment.
I think we can do better for the naming/types?
also for the PreferenceAwarexxx
| * @param attribute the attribute TODO | ||
| * @return the selected index or {@code -1} if selection could not be achieved | ||
| */ | ||
| int selectEndpoint(List<? extends Endpoint<?>> endpoints, String attribute); |
There was a problem hiding this comment.
or should we allow passing this attr/preference to all policies? it can be confusing.
There was a problem hiding this comment.
@machine424 thank you for this contribution
Would you agree to finish this PR with random and power of two choices algorithms only?
I think we all need to put more though into the problem of hashing/sticky session load balancing. I could create a separate issue and one of us would address in a follow-up PR.
| public interface PreferenceAwareLoadBalancer { | ||
|
|
||
| /** | ||
| * TOO SIMPLE Hashing load balancer XXX. TODO |
There was a problem hiding this comment.
Honestly, I need to put more thought into this. As I see it, the problem is the following:
- we have for input either a value provided by the user or computed based on one or more request properties (e.g. client IP or, in the case of sticky sessions, the value of the session id).
- given an input value, we need to be able to stick to the same endpoint (even if other endpoints join or leave)
I'm not sure how to do this right now
Fair enough, I agree with you.` |
Fixes #5154
Add Random and Power of 2 choices policies.
Also, adjust the Round Robin policy to handle a special case.