to generate naon related code in grpc service interface
Commandline example:
protoc --plugin=protoc-gen-java_rpc=build/binaries/java_pluginExecutable/java_plugin \
--java_rpc_out=nano=true:"$OUTPUT_FILE" --javanano_out=ignore_services=true:"$OUTPUT_FILE" \
--proto_path="$DIR_OF_PROTO_FILE" "$PROTO_FILE
- Renamed 'eventGroup' property to 'group' as this what's used elsewhere.
- Moved assignment of the channel before the listener is added as currently
there is a (theoretical) chance that the listener is executed before the assignment
to channel happens, namely in case the Future is already done when the listener
is added.
- Removed comment that seemed out of place / relict.
As part of the effort to remove all blocking bits from the NettyClientStream with
this commit the SendGrpcFrameCommand now takes a stream object instead of the
stream id. This will be necessary as in a non blocking world the stream id might
not have yet been allocated when the SendGrpcFrameCommand gets instantiated.
The QpsClient no longer executes a fixed number of RPCs but runs for a period of time now (see #83).
After some discussion with @ejona86, we also agreed to remove the "server_threads" parameter
and to no longer use a `DirectExecutor` and thus run the QPS Server without any tweaks and
modifications. We believe/hope that this change will make the comparison between the C++ and
Java versions less "Apples and Oranges".
The "client_threads" parameter was renamed to "concurrent_calls" to better reflect what it
acutally does.
Furthermore, I updated the gradle build script to create separate executables for the
client and the server.
I also added a README.
When running benchmarks using the okhttp transport with lots of
streams per channel we would see the occasional GOAWAY frame with
the server logging exceptions of the like "io.netty.handler.codec.http2.Http2Exception: Request stream 575 is behind the next expected stream 583".
As quickly identified by @ejona86, there is a race between creating a new stream id and writing the header on the wire.
Putting both under the same lock ensures that those two always go together.
After this change the errors disappeared. The perf impact should be small as the actual write to
the socket doesn't happen within the lock, but only the scheduling of the write.
Some early grpc users on Android are using a very old Guava. They are
working on upgrading, but it will take time. This alone is not enough
for "old guava" compilibility; expect more to come.
OkHttp no longer cancels all calls on shutdown, as we want to allow
graceful shutdown. Such cancelling behavior will likely be provided by
Channel in the future.
If the transport had started but negotiation had not completed then
previously channel would be null and shutdown would have no effect. Now
we set channel eagerly, but use a separate variable for determining if
it is safe for general use.
OkHttp should now have a thread-safe implementation of newStream.
Previously 'lock' was not held when checking goAway and the checking in
AbstractClientTransport was redundant.
Netty was thread-safe, but it was very hard to tell what guarantees were
necessary and what guarantees each piece was providing.
Channel is available immediately after connect(), so register callbacks
immediately instead of delaying.
Setting channel is now delayed until it is actually safe to use.
zhangkun83
Mugur Marculescu
Xiao Hang
Louis Ryan
Jakob Buchgraber
Nathan Mittler
Jeff Pinner
Eric Anderson
nabeelmian