out how to make it work with "gradle clean build"
Somehow temporaryDir is not created when doing gradle clean build,
so the test complains about path not found
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.
zsurocking
Xiao Hang
Xiao Hang
Jayant Kolhe
Mugur Marculescu
zhangkun83
LisaFC
Dan Ciruli
Louis Ryan
Jakob Buchgraber
Nathan Mittler
Lisa Carey
Jeff Pinner
Tim Emiola
Eric Anderson