'nano=true' still works, but any value is now ignored. This is to align
with our lite flag, but also just because It's Cleaner.
Note that this is counter to what javanano does. Javanano requires all
flags have a value and uses true/false for many values.
Lite already worked by using the protobuf project, but would bring in
extra dependencies that are not intended to work with lite. Although
protobuf is not yet providing a lite package on Maven Central, we will
be able to swap to it once it is available.
There isn't any new original code in the Java portion, except for a new
overload in ProtoUtils that accepts Message instead of MessageLite.
Depending on Message in ProtoUtils allows us to support extra features
out-of-the-box without any changes to the generated code. For example,
JSON encoding could be supported in this way if Marshaller is enhanced.
However, now codegen must be aware of Lite in order to choose with Util
class to use. That is new code.
This requires that all nano protos have .nano in their package name. The
support is expected to be removed from protobuf soon, since using the
deprecated package name causes problems.
check-artifact.sh was broken by the update to Gradle 2.10. We think the
update to Gradle 2.8 caused the POM to start being generated, but this
now fixes it to have the correct contents.
Using addFilter _disables_ the normal POM, so we use setFilter instead.
Fixes#1360
This reduces the necessary number of threads in the application executor
and provides a small improvement in latency (~15μs, which is normally in
the noise, but would be a 5% improvement).
Benchmark (direct) (transport) Mode Cnt Score Error Units
Before:
TransportBenchmark.unaryCall1024 true INPROCESS avgt 10 1566.168 ± 13.677 ns/op
TransportBenchmark.unaryCall1024 false INPROCESS avgt 10 35769.532 ± 2358.967 ns/op
After:
TransportBenchmark.unaryCall1024 true INPROCESS avgt 10 1813.778 ± 19.995 ns/op
TransportBenchmark.unaryCall1024 false INPROCESS avgt 10 18568.223 ± 1679.306 ns/op
The benchmark results are exactly what we would expect, assuming that
half of the benefit of direct is on server and half on client:
1566 + (35769 - 1566) / 2 = 18668 ns --vs-- 18568 ns
It is expected that direct=true would get worse, because
SerializingExecutor is now used instead of
SerializeReentrantCallsDirectExecutor plus the additional cost of
ThreadlessExecutor.
In the future we could try to detect the ThreadlessExecutor and ellide
Serializ*Executor completely (as is possible for any single-threaded
executor). We could also optimize the queue used in ThreadlessExecutor
to be single-producer, single-consumer. I don't expect to do those
optimizations soon, however.
This reduces the number of classes defined, which reduces memory usage.
It also reduces the number of methods defined, which is important
because of the dex limit.
This should have virtually zero performance degradation because the
contiguous switch uses tableswitch bytecode.
This reduces the number of classes defined, which reduces memory usage.
It also reduces the number of methods defined, which is important
because of the dex limit.
This should have virtually zero performance degration because the
contiguous switch uses tableswitch bytecode.
ARG_IN_ and ARG_OUT_ are prefixes as otherwise there could be a name
collision with an oddly-named method. Since the other fields are
prefixed with METHOD_ they can't collide.
There is no need to use ServerMethodDefinition in codegen. The create()
method itself could be helpful to a dynamic HandlerRegistry
implementation, so we won't remove it.
This reduces the amount of logic built into the generated code. If we
swap to an alternative form of decoding we should have greater ability
to adapt the existing API to make use of the new one. Previously most
changes would require duplicating all the nano marshalling code.
- Remove blockingClientStreamingCall() which is not used, and we don't
actually want that API.
- Rename duplexStreamingCall() to asyncDuplexStreamingCall() to align
with other async methods.
- In unary call and client streaming call, do not request for additional
response after the first response.
This gives us more flexibility in API changes in the future.
Unary call and server streaming call should call the flow-control method
call.request() only once. Previously it was called whenever a request
arrives, which is wrong. Now it's fixed.
Resolves#436
Resolves#511.
- In generated code, make CONFIG private and METHOD_* fields public.
METHOD_* fields are MethodDescriptors now, users of the CONFIG field
should switch to using the METHOD_* fields.
- Move MethodType into MethodDescriptor (#529).
- Unify the fully qualified method name. It is fully qualified service
name + slash + short method name. It doesn't have the leading slash.
- HandlerRegistry switches the key from short method name to fully
qualified method name.
- Pass CallOptions to Channel.newCall() and
ClientInterceptor.interceptCall().
- Remove timeout from AbstractStub.StubConfigBuilder and add deadline,
which is stored in a CallOptions inside the stub.
- Deadline is in nanoseconds in the clock defined by System.nanoTime().
It is converted to timeout before transmitting on the wire. Fail the
call with DEADLINE_EXCEEDED if it's already expired.
Other classes are already following the convention that ClientFoo for
client-side, and ServerFoo for server-side. Call has been the black
sheep of the family.
- Call -> ClientCall
- Calls -> ClientCalls
- ForwardingCall* -> ForwardingClientCall*
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.
- 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.
- Stop defining custom architectures because VisualCpp toolchain doesn't
allow it. Reference to built-in architectures 'x86' and 'x86_64' since
they are supported by all toolchains.
- Remove 'local_arch' from platforms. For unsupported platform, we just
do not specify the target.
- Target no more than one platform at a time. This simplifies the build
script a lot.
- Remove the TARGET_ARCHS environment variable. Add system property
``arch`` to override ``osdetector.arch``.
- Add ``vc.disable`` to override the default choice of VisualCpp on
Windows.
- Add ``vc.`` prefix to the properties that are only used with VC++
The plugin has been published on plugins.gradle.org
Conforming to the Gradle standard that plugin IDs must be name-spaced,
the plugin ID has been changed to com.google.protobuf.
Commit 76f0a09 after the previous release
(ws.antonov.gradle.plugins:gradle-plugin-protobuf:0.9.1) defers the
generation of generateProto tasks to post-evaluation of the project,
which make them no longer available in the evaluation phase. We need to
move the manipulation of these tasks to post-evaluation too.
- Add -lprotobuf etc to linker.args if libprotobuf.a etc doesn't exist in
LDFLAGS
- install does not do architecture and dependency check on the artifacts,
because it may produce non-publishable artifacts due to the above
change.
io.grpc.nano sort of seems like a "small" version of grpc-java. And
io.grpc.proto could also mean multiple things. Using "protobuf"
and "protobuf nano" gets us consistent names that are still
understandable, predictable, and more similar to protobuf project
itself.
-Xlint:-options is not available on some earlier JDK 7s, but won't fail
if unsupported. It prevents the warning wanting bootclasspath specified
since target/source is 1.6.
Protoc should be in PATH and the project properties protobuf.include and
protobuf.libs should be set. For example:
gradlew build -Pprotobuf.include=C:\path\to\protobuf-3.0.0-alpha-2\src ^
-Pprotobuf.libs=C:\path\to\protobuf-3.0.0-alpha-2\vsprojects\Release
When running more than once, it is probably more convenient to create
%HOMEDRIVE%%HOMEPATH%\.gradle\gradle.properties with contents like:
protobuf.include=C:\\path\\to\\protobuf-3.0.0-alpha-2\\src
protobuf.libs=C:\\path\\to\\protobuf-3.0.0-alpha-2\\vsprojects\\Release
The gradle task testNanoGolden fails because the temporary folder it tries to use does not exist.
The task tries to write files to temporaryDir which points to ./compiler/build/tmp/testNanoGolden/ on my machine.
The directory does not exist by default and so the run_nano_test.sh fails.
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
A Gradle protoc plugin is used for generating and compiling the grpc
codegen. The code organization was changed to match what Gradle expects.
Proto 3 is now required.
of opensource protobuf.
- Moved to third_party under GRPC Java directory
- Using Gradle to build
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=84053803
Eric Anderson