Although the changes were determined automatically, they were manually
applied to the codebase.
ClientCalls actually has a bug fix, since the suggestion to add
interrupt() made it obvious that interrupted() was inappropriate.
The jsonp dependency string is no longer shared because it was only used
in one place and someone trying to compile the examples using a new
build.gradle will need to add that dependency. It was a bit complex to
follow how libraries.jsonp worked and it wasn't really adding any value
in this particular case.
Specifying the outer class is a pretty common convention and avoids the
outer classname changing depending on the contents of the proto file (as
can be seen if outer_classname isn't specified in the route guide
example). To avoid colliding, convention has it end in "Proto".
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.
ServerCall already had "headers must be sent before any messages, which
must be sent before closing," but the implementation did not enforce it
and our async server handler didn't obey.
The benefit of forcing sending headers first is that it removes the only
implicit call in our API and interceptors dealing just with metadata
don't need to override sendMessage. The implicit behavior was bug-prone
since it wasn't obvious you were forgetting that headers may not be
sent.
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.
Client:
* New ManagedChannel abstract class.
* Adding ping to Channel.
* Moving builders and implementations to internal.
Server:
* Added lifecycle management API to Server (mirroring ManagedChannel).
* Moved ServerImpl, AbstractServerBuilder and handler registries to internal.
* New ServerBuilder abstract class (mirroring ManagedChannelBuilder).
Fixes#545
Reserve io.grpc for public API only, and all internal stuff in core to
io.grpc.internal, including the non-stable transport API.
Raise the netty/okhttp/inprocess subpackages one level up to io.grpc,
because they are public API and entry points for most users.
Details:
- Rename io.grpc.transport to io.grpc.internal;
- Move SharedResourceHolder and SerializingExecutor to io.grpc.internal
- Rename io.grpc.transport.{netty|okhttp|inprocess} to
io.grpc.{netty|okhttp|inprocess}
- 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*
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.
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``.
- 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.
ServerImpl.start() now throws IOException to make the error explicit.
This was previously being papered over by wrapping the exception in
RuntimeException.
1. Adds <property name="separateLineBetweenGroups" value="true"/> to CustomImportOrder to enfore blank line between imports groups.
2. Uses checkstyle 6.5, which fixed a bug of "CustomImportOrder checks import sorting according to ASCII order instead of case-insensitive alphabetical order".
Failing disabled by default, but setting checkstyle.ignoreFailures=false
in ~/.gradle/gradle.properties enables failing. Travis will always run
with such failing enabled.
The checkstyle.xml is a slightly modified version of the upstream Google
checkstyle configuration. All changes have comment describing them.
Lots of warnings were corrected. Examples is the only project that has
warnings still, as the necessary changes require some thought.
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
This change loses asynchronous notification of channel state-change and
a way to wait until the channel is actually connected. Both of these are
expected to be added back as part of a health API. The important
distinction from Service is that ChannelImpl never permanently fails and
can revert from being started to connecting again.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83875407
The current signatures are not more useful than the async counterparts,
we'd rather not have them until more sepcific requirement comes up.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=80402647
Carl Mastrangelo