- streaming ping-pong messages per second
- unary response bandwidth in megabits per second
- streaming response bandwidth in megabits per second
- streaming server that obeys outbound flow control
We know the size won't be more than serializedHeaders.length, is
unlikely to be fewer, and very unlikely to be substantially fewer. This
prevents us from needing to resize the array in all cases.
Resolves#321
By default, ArrayDeque will be of size 16, which is an overkill for most
calls. "4" is not a magical number itself, but seems a better guess than
16 since we do have some knowledge of how much it will contain.
Resolves#320
1. update connection window when receives DATA for existed streams.
2. kill the connection when receives unknown (not exist and never existed) stream id.
When shutting down the Netty event loop, we have already guaranteed that
all users of it are no longer running. Doing a shutdownGracefully is
just delaying graceful JVM termination by two seconds. This is very
noticeable for short-lived processes, like our integration tests.
We would actually also prefer to shutdown quickly and get a
RejectedExecutionException for any newly queued tasks, because that
would be a legitimate bug.
shutdown() is deprecated, thus we do shutdownGracefully with a timeout
of 0.
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.