This can avoid creating an additional 736 tasks (previously 502 out of
1591 were not created). That's not all that important as the build time
is essentially the same, but this lets us see the poor behavior of the
protobuf plugin in our own project and increase our understanding of how
to avoid task creation when developing the plugin. Of the tasks still
being created, protobuf is the highest contributor with 165 tasks,
followed by maven-publish with 76 and appengine with 53. The remaining
59 are from our own build, but indirectly caused by maven-publish.
all: Update netty to 4.1.77.Final and netty_tcnative to 2.0.53.Final
Also switches to a non-release version of rules_jvm_external to allow Bazel build to work with artifact classifiers.
This moves our depedencies into a plain file that can be read and
updated by tooling. While the current tooling is not particularly better
than just using gradle-versions-plugin, it should put us on better
footing. gradle-versions-plugin is actually pretty nice, but will be
incompatible with Gradle 8, so we need to wait a bit to see what the
future holds.
Left libraries as an alias for libs to reduce the commit size and make
it easier to revert if we don't end up liking this approach.
We're using Gradle 7.3.3 where it was an incubating fetaure. But in
Gradle 7.4 is became stable.
runUnaryBlockingClosedLoop is failing after 10.3s, which means 5.3s was
probably spent loading the LoadWorker. That means things are likely
indeed slow enough that 5s isn't enough time to wait for the server to
start. A successful execution of runUnaryBlockingClosedLoop takes
12.1 seconds, which again points to general slow execution.
This should fix test failures on aarch64.
```
expected to be less than: 0.0
but was : 0.0
at app//io.grpc.benchmarks.driver.LoadWorkerTest.assertWorkOccurred(LoadWorkerTest.java:198)
at app//io.grpc.benchmarks.driver.LoadWorkerTest.runUnaryBlockingClosedLoop(LoadWorkerTest.java:90)
```
runUnaryBlockingClosedLoop() has been failing but the other tests
suceeding. The failure is complaining that getCount() == 0, which means
no RPCs completed. The slowest successful test has a mean RPC time of
226 ms (the unit was logged incorrectly) and comparing to x86 tests
runUnaryBlockingClosedLoop() is ~2x as slow because it executes first.
So this is probably _barely_ failing and 4 attempts instead of 3 would
be sufficient. While the test tries to wait for 10 RPCs to complete, it
seems likely it is stopping early even for the successful runs on
aarch64. There are 4 concurrent RPCs, so to get 10 RPCs we need to wait
for 3 batches of RPCs to complete which would be 1346 ms (5 loops)
assuming a 452 ms mean latency. Bumping timeout by 10x to give lots of
headroom.
This allows using LoadClient with xDS.
The changes to SocketAddressValidator are a bit hacky, but we really
don't care about cleanliness there. Eventually on client-side, we should
be deleting the unix special case entirely, as we'll have a unix name
resolver.
Fixes#8877
These changes make the build compatible with Gradle 7, except for
Android which requires plugin updates.
I removed animalsniffer from binder because it did nothing (as there
were no signatures) and it was failing after setting toolVersion. It
failed because animalsniffer is only compatible with java plugin. After
this change I put the withId(animalsniffer) loading inside the
withId(java) to avoid a plugin ordering failure. That made it safe again
for binder to load animalsniffer, but it is still best to remove the
plugin from binder as it is misleading.
I did not upgrade Android plugin versions as newer versions (even 3.6)
require dealing with androidx (#8421).
This can be used by annotation processors to avoid processing the
gRPC-generated code. The normal Generated annotation only has SOURCE
retention, so isn't available to annotation processors.
I don't include the service name within the annotation as that assumes
we'll never have need for any other type of generated class. If there's
a request for exposing service name via an annotation in the future, we
can make an RpcService annotation or the like.
Fixes#8158
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 Jetty ALPN is not needed for benchmarks. This change removes the
-javaagent lines from the benchmarks/build.gradle file as suggested by
@ejona86.
The shell script references the Jetty ALPN agent stored in ~/.gradle which
is not available when just using the application artifacts. interop-testing
has a hack to make the agent work, but we don't really care about "plain"
Java performance for benchmarks so it is easier to just remove it.
It's a lot of code and there are classes in Guava are better. This was noticed
with a lint checker. This commit does change the error-handling behavior, as
previous the code wrongly cancelled the Future instead of setting it to have an
exception.
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.
'runtime' is the old classpath, pre-java-library plugin. We could swap to
'runtimeClasspath', but it is cleaner to just use startScript's defaults. We
already use that approach in interop-testing.
Fixes#7218
- 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.
Bump jmh plugin to version 0.5.0. Put junit and mockito to test dependency. Eliminated jmh plugin config workaround for the known issue in previous version.
Examples and android projects were left unchanged. They can be changed
later.
No plugin versions were changed, to make this as non-functional of a
change as possible. Upgrading Gradle to 5.6 was necessary for
pluginManagement in settings.gradle.
NETTY_LOCAL seem to have a flow control issue. Disable it since we don't
really look at it very often and we care about the
streamingCallsMessageThroughput benchmark.
This replaces FlowControlledMessagesPerSecondBenchmark, except it does not
avoid local flow control issues via request(5). If hacking in a request(5),
this benchmark produces similar results (non-direct: 671k vs previously 641k
msg/s).
This is equivalent to UnaryCallResponseBandwidthBenchmark and
StreamingResponseBandwidthBenchmark, although without the interface selection
logic (which allows for traffic shaping).
TearDown is guaranteed to execute after Setup; there is no synchronization
necessary. Although the volatile doesn't hurt anything functionally, it is
misleading and confusing.
It is basically the same as TransportBenchmark without protobuf, smaller
payload, and only Netty. It does show latencies around 66 µs instead of
TransportBenchmark's 70 µs on my laptop, but a quick conversion of
TransportBenchmark to ByteBufOutputMarshaller made it 66 µs as well.
* compiler: Use 'SERVICE_NAME' instead of duplicated '$Package$$service_name$'
* compiler: Align indentation
* Fix typo
* Add modified golden files and all re-generated code to meet Travis CI and Windows build requirements
See PR #5943
* Polishing
This commit swaps to using a Sync task to place generated code in the
src/generated folder instead of the gradle-protobuf-plugin's
generatedFilesBaseDir. This provides much nicer results on failed
builds, and you will no longer see all the generated files deleted.
But at the same time the Sync task makes it easy to only copy the
grpc-generated code. This was not previously done because we were lazy
and using generatedFilesBaseDir, which made it difficult to treat the
services differently from the messages.
For security, we should change http into https links.
Co-Authored-By: Nguyen Van Trung [trungnvfet@outlook.com](mailto:trungnvfet@outlook.com)
Signed-off-by: Nguyen Quang Huy [huynq0911@gmail.com](mailto:huynq0911@gmail.com)
Eric Anderson