-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross service call with grpc-xds v1.67.1 #11611
Comments
Can you attach the debug logs? |
Here if you notice the server IP: 10.51.241.228 is correctly sending and receiving requests via service But just after the last timestamp:
it starts calling The same is not happening for the version 1.66 |
Istio is broken with gRPC Java 1.67+: istio/istio#53532 . I wonder if it can send responses on the wrong stream, in addition to closing other streams. (... although the resource names would also have to be wrong...) |
What version of gRPC-Java are you using?
v1.67.1
What is your environment?
jdk 21 eclipse temurin
What did you expect to see?
We are using istio version 1.20.1 and with this we are using grpc-proxyless setup for client side load balancing with grpc-xds in production in a multi-cluster environment. This setup has been working fine up until now.
Our service connects to several grpc targets which are present in other cluster, so we expect the routing is done correctly to each services as they have different service endpoints.
What did you see instead?
We see that the request is mixing between the services which are present in other cluster.
We were receiving status code as 12, when we turned on the debug logs and tried investigating further, we saw that the requests that were supposed to go on service A, few of the request were going to service B and vice versa. We are not sure why this is happening and it is not easier to reproduce as well as it happens randomly on different pods and persists for a longer time.
Lets say when a call to service A is going to service B, we identified the IP and killed that pod. Post that it picked up another IP of service B and started sending it request.
Since there were lots of changes related to load-balancing and also XDS fallback where XDS client was seaprated for each target, I am suspecting some issues in these modules.
We verified by reverting and upgrading multiple times that this is only happening for version > 1.66
The text was updated successfully, but these errors were encountered: