I am not familiar with java-control-plane, so I can't answer that. You might try asking in their developer community.
On Mon, Aug 16, 2021 at 10:55 AM Lukáš Drbal <lukas.dr...@gmail.com> wrote: > Hello Mark, > > as first thanks a lot for Your replay, it is more clear for me now. > > Do you have any idea how to distinguish connected clients? I was looking > for some information which I can use but I don't see anything usable in > NodeGroup interface [1]. It provides access just for `Node` protobuf object > but I don't see anything usable there. > > Any idea or example? > > Thanks! > > [1] > https://github.com/envoyproxy/java-control-plane/blob/main/cache/src/main/java/io/envoyproxy/controlplane/cache/NodeGroup.java > On Monday, August 16, 2021 at 7:15:11 PM UTC+2 Mark D. Roth wrote: > >> The xDS protocol does not require the node information to be sent by the >> client for every request on the stream; the client needs to send it only on >> the first request on the stream. Quoting this section of the xDS spec >> <https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#basic-protocol-overview> >> : >> >> Only the first request on a stream is guaranteed to carry the node >>> identifier. The subsequent discovery requests on the same stream may carry >>> an empty node identifier. This holds true regardless of the acceptance of >>> the discovery responses on the same stream. The node identifier should >>> always be identical if present more than once on the stream. It is >>> sufficient to only check the first message for the node identifier as a >>> result. >> >> >> The Java implementation may currently happen to send the node information >> with every request on the stream, but it's not required to do that, and >> your xDS server should not expect that behavior. I think you need to >> change your xDS server to look at the node information on the first request >> on the stream and store the node.cluster field so that it knows the value >> when it sees subsequent requests on the same stream. >> >> I hope this information is helpful. >> >> On Mon, Aug 16, 2021 at 2:30 AM Lukáš Drbal <lukas...@gmail.com> wrote: >> >>> Hello everyone, >>> >>> We are trying to setup routing via XDS to our GRPC services. Routing >>> should be based on `node.cluster` information provided from client. >>> >>> Basically we would like to have 2 groups of GRPC clusters (priority and >>> normal) with same endpoints and choose right one by client `node.cluster` >>> identification. >>> >>> I have very minimal setup [1] which works absolutely as we expected for >>> java client but doesn't work for C++ (and grpc_cli). Node hashing >>> implementation [2]. This is minimal setup to reproducing this behaviour, >>> regular routing is more complicated. >>> >>> From log perspective it looks like from C++ xds server receive >>> `node.cluster` information just in first request. >>> >>> From java I see cluster in all requests: >>> grpc-default-executor-0] INFO org.example.xds.routing.XdsServer - >>> Routing [priority] to priority group. [grpc-default-executor-1] INFO >>> org.example.xds.routing.XdsServer - Routing [priority] to priority group. >>> [grpc-default-executor-1] INFO org.example.xds.routing.XdsServer - Routing >>> [priority] to priority group. [grpc-default-executor-0] INFO >>> org.example.xds.routing.XdsServer - Routing [priority] to priority group. >>> [grpc-default-executor-1] INFO org.example.xds.routing.XdsServer - Routing >>> [priority] to priority group. [grpc-default-executor-2] INFO >>> org.example.xds.routing.XdsServer - Routing [priority] to priority group. >>> [grpc-default-executor-1] INFO org.example.xds.routing.XdsServer - Routing >>> [priority] to priority group. [grpc-default-executor-2] INFO >>> org.example.xds.routing.XdsServer - Routing [priority] to priority group. >>> >>> But from cli / c++ I see cluster just in first request: >>> [grpc-default-executor-0] INFO org.example.xds.routing.XdsServer - >>> Routing [priority] to priority group. [grpc-default-executor-0] INFO >>> org.example.xds.routing.XdsServer - Routing [] to normal group. >>> [grpc-default-executor-0] INFO org.example.xds.routing.XdsServer - Routing >>> [] to normal group. >>> >>> This leads to expected error when c++ client is trying to get priority >>> listeners and routes from default group. >>> >>> Can somebody give me any hint what's wrong here? >>> >>> Thanks a lot! >>> >>> L. >>> >>> [1] https://github.com/LesTR/xds-routing-test >>> [2] >>> https://github.com/LesTR/xds-routing-test/blob/master/src/main/java/org/example/xds/routing/XdsServer.java#L61 >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "grpc.io" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to grpc-io+u...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/grpc-io/1de7e140-862f-414f-b25a-7b1afc4069can%40googlegroups.com >>> <https://groups.google.com/d/msgid/grpc-io/1de7e140-862f-414f-b25a-7b1afc4069can%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Mark D. Roth <ro...@google.com> >> Software Engineer >> Google, Inc. >> > -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to grpc-io+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/19380de0-9db6-4095-a120-ae40c453a9e8n%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/19380de0-9db6-4095-a120-ae40c453a9e8n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Mark D. Roth <r...@google.com> Software Engineer Google, Inc. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAJgPXp6X%3DTChn0zWzbkgT3Sk-%3Dp4Ac9Gi5qAi3TuYAPpG4OGrw%40mail.gmail.com.
