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.
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.
This makes the reconfiguration code more concise.
- Remove configureNewStub().
- Add mutation methods withDeadlineNanoTime(), withChannel() etc that
returns the reconfigured stub.
- 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.
10 years exceeds the maximum for some systems at the moment. Change to 1
year to workaround such systems while they get changed. And since "have
the default be a large number instead of not present" is a temporary fix
anyway.
Delaying creating the exception produces a much more useful exception.
The status code, description, and exception type are all identical. The
only difference in the backtrace.
Stubs don't have any timeout. However, MethodDescriptor does and
requires a timeout. We really want "no timeout," which is infinite, but
we use 10 years as the next best thing. CallOptions will end up fixing
this hack as MethodDescriptor will no longer have timeout.
Before, the hard-coded 1s didn't matter, because nobody was observing
it. Since 77878a0 it is now being sent to servers, and some servers
enforce it. Oops.
Previously, it always threw a RuntimeExecutionException with a
StatusRuntimeException within (since the only callers of setException()
provide a StatusRuntimeException).
Resolves#507
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*
call super.start(), and makes the subsequent use of other methods on the
call throw IllegalStateException.
Create ClientInterceptors.CheckedForwardingCall that handles exception
in start logic.
Create Forwarding[Server]Call[Listener] for generic decoration use
cases, with an abstract delegate() for flexibility.
Create SimpleForwarding[Server]Call[Listener] to replace now deprecated
forwarding classes.
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.
Carl Mastrangelo
Eric Anderson
Louis Ryan
Xudong Ma
nmittler
Kun Zhang