interop-testing: LB that adds the rpc-behavior to calls #9186
Conversation
interop-testing/src/main/java/io/grpc/testing/integration/RpcBehaviorLoadBalancerProvider.java
Outdated
Show resolved
Hide resolved
interop-testing/src/main/java/io/grpc/testing/integration/RpcBehaviorLoadBalancerProvider.java
Outdated
Show resolved
Hide resolved
interop-testing/src/main/java/io/grpc/testing/integration/RpcBehaviorLoadBalancerProvider.java
Outdated
Show resolved
Hide resolved
interop-testing/src/main/java/io/grpc/testing/integration/RpcBehaviorLoadBalancerProvider.java
Show resolved
Hide resolved
| @@ -0,0 +1 @@ | |||
| io.grpc.testing.integration.RpcBehaviorLoadBalancerProvider | |||
There was a problem hiding this comment.
do you want to use it to register this provider to the LoadBalancerRegistry?
There was a problem hiding this comment.
Yes exactly, this file will be in the classpath and read automatically to register any LB providers in it.
There was a problem hiding this comment.
yea ok, is it possible to call register before test and de-register after? I strongly feel that our test provider should better not mix with production service providers. But I don't know how bad it is. wdyt?
There was a problem hiding this comment.
That was my initial plan, but @ejona86 suggested this approach. Eric, would our interop-testing project META-INF ever mingle with the real one(s)?
There was a problem hiding this comment.
This doesn't mix with our production service providers because it is part of interop-testing. I don't think we should register this per-test, because that's not at all how the test architecture works, which is also why we aren't doing that for Ivy's interop tests. The xds interop tests don't know what test they are running, so they can't at all register per-test (vs just having hacks). We'd have to add a new argument for the binary and I don't think that really provides any value.
| private static final String RPC_BEHAVIOR_HEADER_KEY = "rpc-behavior"; | ||
|
|
||
| private final SubchannelPicker delegatePicker; | ||
| private final String rpcBehavior; |
There was a problem hiding this comment.
if i understand correctly, the picker is created in managedChannel syncContext, while pick subchannel is called from created client stream, so volatile would be ideal here, right? cc. @ejona86
There was a problem hiding this comment.
You are right, except for the volatile part. The picker only needs to worry about synchronizing with itself, and it isn't changing rpcBehavior, so everything is okay.
| @@ -0,0 +1 @@ | |||
| io.grpc.testing.integration.RpcBehaviorLoadBalancerProvider | |||
There was a problem hiding this comment.
yea ok, is it possible to call register before test and de-register after? I strongly feel that our test provider should better not mix with production service providers. But I don't know how bad it is. wdyt?
temawi
added
the
TODO:backport
temawi
removed
the
TODO:backport
This load balancer can be used to trigger custom behavior on servers for all calls that use the LB.