Previously generated files were deleted at configuration time. Running
non-build tasks such as ``clean`` or ``tasks`` would delete the
generated files and tracked by git, which is annoying. Now we delete
them only before the ``generateProto`` task, which solves the problem.
After this change, the case that ``generateProto`` is not executed at
all, is no longer covered. However, it is much less likely than the
still-covered case that ``generateProto`` is not re-generating all files
due to misconfiguration.
This allows people who cannot run the pre-compiled ``protoc`` pulled
from Maven Central to use their own ``protoc``.
Upgrade to protobuf-gradle-plugin:0.4.1 to display error messages of
protoc failures.
isReady() can provide pushback while the call is in progress, but it
can also provide the pushback necessary when the client creates more
streams than permitted by MAX_CONCURRENT_STREAMS.
As part of this commit, OkHttp is now calling onReady() after call
creation (it previously never called onReady()).
Since commit 287a27a the ``grpc`` codegen plugin must be explicitly
added to the ``plugins`` block of the source set, while it didn't.
Remove the generated code before recompiling it to prevent such issue
from being missed by tests.
Ideally OKHttp wouldn't do blocking I/O during start(), but it does and
fixing it is non-trivial. OkHttp can either throw an exception when it
encounters an error during start or it can shut itself down. Both
require changes in ChannelImpl, so we just choose to keep OkHttp's
current behavior and deal with it in ChannelImpl.
Resolves#404
Add the gRPC codegen executable and the root ``build.gradle`` (where the
protoc version is) to the inputs of ``generateProto`` task, so that the
task is rerun when either of them has changed.
The previous output was not generated with proto3-alpha-2. This has been
regenerated using protoc on Maven Central, so it should be the same
output everywhere.
- Switch all system properties to project properties.
- Use the ``javaLocalNamingStyle`` instead of the
``dot.delimited.style`` for property names, so that it can be directly
referenced by ``rootProject.propertyName``.
- Recommend users to put GRPC-specific properties in project-level
``build.properties`` instead of the user-level.
This makes it easy to run our test client/server without the "magic" of
executing directly from Gradle. This makes it more obvious what code is
being run and prevents confusion due to Gradle "hanging" when starting
the server.
This also fixes build errors when running 'installDist' at the root
project.
Resolves#357
- Add project property ``grpc.skip.codegen``, which is false by default.
People who don't change the codegen nor the proto files can set it to
true so that they don't need to set up C++ compilation.
- Check in all generated files under ``src/generated``.
BufferingHttp2ConnectionEncoder.
Currently we don't check this setting when handling a streamClosed()
event. If the setting has lowered prior to this event, the stream
creation could fail.
After running tests, you can run jacocoTestReport. The jacocoTestReport
task does not depend on the tests, so they should be run separately.
There is still a lot of noise in the jacoco output since we aren't yet
filtering generated code.
This makes it easy to run our test client/server without running gradle
every time. For the moment we run 'installDist' in our script since that
is not performed as part of 'build' or 'assemble'. Once we fix our
scripts and improve the documentation, we can remove running installdist
from our script.
It seems almost every developer has caused Travis CI to break due to
checkstyle failures. To prevent further breakages, checkstyle will now
fail the build by default.
Specifying checkstyle.ignoreFailures=true in ~/.gradle/gradle.properties
will turn the failures into warnings, which was the old behavior.
Client closing doesn't really many anything special, since it is still
fully-operational. We don't want a later goAwayStatus() from getting
squelched because we were shutting down.
Motivation:
We are currently blocking in NettyClientTransport.newStream(...) until the channel is active and/or the TLS Handshake is complete.
In certain cases this may lead to deadlock of the eventloop, see #116 for details.
Modifications:
Remove all blocking by buffering writes until the channel is ready to receive those i.e. it is active, TLS is negotiated or the HTTP to HTTP/2 upgrade was sucessfull.
Result:
No more blocking parts when using Netty on the client side.
Kun Zhang
Louis Ryan
nmittler
Xudong Ma
Eric Anderson
Mark Kelly
Jakob Buchgraber