[TEST] Extend unicast ports generation to support more concurrent clusters #8634
Conversation
| default: | ||
| //ports can be reused as suite or test clusters are never run concurrently | ||
| //prevent conflicts between jvms by never going above 9 | ||
| return RandomizedTest.randomIntBetween(1, 9); |
There was a problem hiding this comment.
why not round robin on this? I think the randomness still allows us to have collisions and will keep us wondering.
+1 on the insight that suite and test scope don't co-exists! Also, this makes us one step closer to using it randomly in our global cluster scope.
There was a problem hiding this comment.
why not round robin on this? I think the randomness still allows us to have collisions and will keep us wondering.
the assumption is that only one cluster with either SUITE or TEST is on at a given time within a jvm, so there shouldn't be conflicts. Randomizing is not strictly necessary (we just have to skip 0 and make sure not to go above 9) but it does help verifying our assumption? I am conflicted here...
+1 on the insight that suite and test scope don't co-exists! Also, this makes us one step closer to using it randomly in our global cluster scope.
Indeed, this change should make this possible as the next step!
There was a problem hiding this comment.
Randomness is awesome when it's needed, but also adds complexity. Also, we need to let the OS free the old ports before reusing them. I think having some gaps is good? I'm hoping a cycle of 9 is good enough, but we'll see...
|
I like it. Thx Luca for looking into this. Left two comments. |
javanna
force-pushed
the
test/unicast_conf
branch
from
69cb7c2
to
54eac72
Compare
|
Thanks @bleskes updated |
| @@ -39,6 +39,8 @@ | |||
| final Settings nodeSettings; | |||
| final Settings transportClientSettings; | |||
|
|
|||
| private static final AtomicInteger portCounter = new AtomicInteger(); | |||
There was a problem hiding this comment.
this is used for the unicast discovery - can we this back to the class? (or reuse the old variable :) )
|
@javanna two little minor details and we're done. thx. |
|
thanks @bleskes can you have another look please? |
|
LGTM! |
…sters Make it possible to run multiple tests with unicast configuration, by assigning ports based on their test scope. Every jvm still gets its own port range based on the jvm id, but we now make sure that the different jvms ranges never overlap. The global cluster gets a reserved port range, while SUITE and TEST scopes are treated equally, just assuming that they never run concurrently on the same jvm, thus ports can be safely reused. Closes elastic#8634
javanna
force-pushed
the
test/unicast_conf
branch
from
406bfbc
to
e07b0de
Compare
…sters Make it possible to run multiple tests with unicast configuration, by assigning ports based on their test scope. Every jvm still gets its own port range based on the jvm id, but we now make sure that the different jvms ranges never overlap. The global cluster gets a reserved port range, while SUITE and TEST scopes are treated equally, just assuming that they never run concurrently on the same jvm, thus ports can be safely reused. Closes elastic#8634
None gateway was removed in master hence setting it to local is the default there, applied in #8634 . 1.x still requires setting the geteway type to local explicitly
The current
UnicastZenonly supports up to 10 different clusters per jvm, after which it generates ports that overlap between different jvms.Make it possible to run multiple tests with unicast configuration, by assigning ports based on their test scope.
Every jvm still gets its own port range based on the jvm id, but we now make sure that the different jvms ranges never overlap. The global cluster gets a reserved port range, while SUITE and TEST scopes are treated equally, just assuming that they never run concurrently on the same jvm, thus ports can be safely reused.