Resolves#7741
Some of the static methods in generated code have the same method name but different package name, such `ClientCalls.asyncClientStreamingCall` and `ServerCalls.asyncClientStreamingCall`. It's less readable using static import than using full-qualified method name in-place.
The proto field is named as num_failures but its comment is saying it is for number of RPCs that failed to record a remote peer. RPC failed == RPC failed to record a remote peer was true previously (so no existing tests should be affected by this changed) as server completed RPCs immediately. It is no longer true with server capability to keep the call open/delayed.
This change clarifies the proto definition for stats RPC. rpcs_by_peer is for recording RPCs succeeded and num_failures is for RPCs failed. RPCs in the flight when the stats call times out are not counted towards any of the stats.
Update xDS interop test proto to aggregate accumulated stats based on RPC methods (mirroring 643e5bcd1e8db931cf76a3be19cd9bba223ee987 in C-core's change). Updated the xDS interop test client to support querying accumulated stats aggregated to RPC methods.
The main() Thread will call tearDown() itself. It appears this
redundancy has existed since e813eaae2f, where the normal error handling
was enhanced at the same time as cleaning up resource management. The
cleanup should have made it obvious the hook was no longer needed, but
alas. Technically, it did originally provide a purpose if setup()
failed, but it would have been better to just move setup() into the
try-catch instead. Today it doesn't even provide that purpose.
Most of these are easy "replace X with Y."
The CreateStartScripts changes were because the scripts were being included in
the output zip/tar multiple times. The was because they were all using the same
output directory, and the entire output directory was being included for each.
The output directory tmp/ was particularly poor because other tasks were
dumping things into it, so our zip/tar was including those junk files as well.
This prevents grpc-xds and its transitive dependencies from being included
twice in distTar and distZip, which reduces the size from 60 MB to 40 MB. It
does mean that interop-testing as a whole depends on xds, but that should not
be an issue any longer. It was an issue before we started providing grpc-xds on
Maven Central.
If the server fails (e.g.: with an unimplemented status), the test still succeeds.
This change adds assertions to check the status code as well as the expected number of responses.
This is a java analogue of the C++ test added in grpc/grpc#19623.
Proto changes were synced from grpc/grpc-proto
This client is suitable for testing fallback with any "grpclb" load-balanced service, but is particularly meant to implement a set of test cases described in an internal doc titled "DirectPath Cloud-to-Prod End-to-End Test Cases", section "gRPC DirectPath-to-CFE fallback".
- Use gradle configuration `api` for dependencies that are part of grpc public api signatures.
- Replace deprecated gradle configurations `compile`, `testCompile`, `runtime` and `testRuntime`.
- With minimal change in dependencies: If we need dep X and Y to compile our code, and if X transitively depends on Y, then our build would still pass even if we only include X as `compile`/`implementation` dependency for our project. Ideally we should include both X and Y explicitly as `implementation` dependency for our project, but in this PR we don't add the missing Y if it is previously missing.
Currently the classpath for all startscripts in interop-testing includes alpnagent and grpc-xds, even if a lot of startscripts don't need them. Made a change to only include alpnagent or grpc-xds when a startscript really needs it.
This reverts commit c5f48b8e38. (#6780)
Revert because caused a regression in the ALTS tests. https://source.cloud.google.com/results/invocations/691d9965-fea1-487d-b606-352a5234039e/targets/grpc%2Fcore%2Fpull_request%2Flinux%2Fgrpc_interop_toprod/log
2020-03-01 20:02:12,491 Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/lang3/SystemUtils
at io.grpc.alts.CheckGcpEnvironment.isRunningOnGcp(CheckGcpEnvironment.java:69)
at io.grpc.alts.CheckGcpEnvironment.isOnGcp(CheckGcpEnvironment.java:44)
at io.grpc.alts.ComputeEngineChannelBuilder.(ComputeEngineChannelBuilder.java:62)
at io.grpc.alts.ComputeEngineChannelBuilder.forTarget(ComputeEngineChannelBuilder.java:72)
at io.grpc.alts.ComputeEngineChannelBuilder.forAddress(ComputeEngineChannelBuilder.java:77)
at io.grpc.testing.integration.TestServiceClient$Tester.createChannel(TestServiceClient.java:399)
at io.grpc.testing.integration.AbstractInteropTest.setUp(AbstractInteropTest.java:309)
at io.grpc.testing.integration.TestServiceClient.setUp(TestServiceClient.java:198)
at io.grpc.testing.integration.TestServiceClient.main(TestServiceClient.java:56)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang3.SystemUtils
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 9 more
In v1.27.0 release the grpc-interop-testing artifact in maven includes grpc-xds, but grpc-xds is not yet published. It should be removed from the dependency list in maven artifact.
Yifei Zhuang
ZHANG Dapeng
Sergii Tkachenko
Chengyuan Zhang
sanjaypujare
Eric Anderson
Eric Gribkoff
Trustin Lee
Philippe Laflamme
Jihun Cho
apolcyn
ZhenLian