This can provide a ~2x performance increase to Netty and 40% increase
for OkHttp. Netty async saw a ~3x gain from MigratingDeframer, so
blocking trails behind a bit. But OkHttp's async gains from
MigratingDeframer were also 40%, so this provides the same gain to
blocking.
This splits server-side flow control from client-side, but tailors the API for
each case. Client-side continues having disableAutoRequestWithInitial(). While
client-side could have disableAutoRequest(), it seems like it will only rarely
be used and disableAutoRequestWithInitial(0) isn't that bad. So we leave it off
for now; we can always add it in the future.
Add a new disableAutoRequest method that disables all automatic requests while disableAutoInboundFlowControl maintains existing behavior.
The default behavior of requesting initial messages is applied even if disableAutoInboundFlowControl is called. ServerCalls disables all automatic flow control which is much more useful in case the user can't handle incoming messages until some time after the call has started. This change creates a new StartableListener that has an onStart method that is invoked when the call is started which makes initial requests if necessary.
See #6806
This is already in the documentation in CallStreamObserver, but if the user
gets here the error didn't provide an actionable next step. The message now
provides more help of how they should have called the methods instead of
feeling more like a brick wall.
* stub: ignore unary response msg if status is not OK
* stub: throw if no msg with OK status
* address the comment, improve tests.
* fix error message
* fix error message
* improve naming of the tests
* call onCompleted on success unary flow
* fix test
* handle errors for delayed unary message sending
* clean up the onCompleted/onError logic
* use hasMessageThat to produce better error message when fail
This reverts commit 6d44f46f18.
This is causing a test to hang internally. I am currently expecting that
the shutdown logic of the test is broken, but it will take time to
diagnose. Thus, revert this for the moment.
Interceptors need to see the onClose to clean up properly.
This also changes an isInterrupted() to interrupted(), since previously
the interrupted flag was still set when InterruptedException was thrown.
This caused an infinite loop with the new code. Previously, all callers
immediately re-set the interrupted flag, so there was no issue.
Fixes#5576
The `ThreadlessExecutor` currently used for blocking calls uses `LinkedBlockingQueue` which is relatively heavy both in terms of allocations and synchronization overhead (e.g. when compared to `ConcurrentLinkedQueue`). It accounts for ~10% of allocations and ~5% of allocated bytes per-call in the `TransportBenchmark` when using in-process transport with [stats and tracing disabled](https://github.com/grpc/grpc-java/issues/5510).
Changing to use a `ConcurrentLinkedQueue` results in a ~5% speedup of that benchmark.
Before:
```
Benchmark (direct) (transport) Mode Cnt Score Error Units
TransportBenchmark.unaryCall1024 true INPROCESS avgt 60 1877.339 ± 46.309 ns/op
TransportBenchmark.unaryCall1024 false INPROCESS avgt 60 12680.525 ± 208.684 ns/op
```
After:
```
Benchmark (direct) (transport) Mode Cnt Score Error Units
TransportBenchmark.unaryCall1024 true INPROCESS avgt 60 1779.188 ± 36.769 ns/op
TransportBenchmark.unaryCall1024 false INPROCESS avgt 60 12532.470 ± 238.271 ns/op
```
This restrains a cancellation Exception when an onCancelHandler
is set in ServerCallStreamObserverImpl.
Signed-off-by: Venil Noronha <veniln@vmware.com>
* Reflowed some method parameters to be on the same line, else one
parameter per line
* Used `@link` where appropriate
* Made some parameters non-final where it had no effect
* Renamed some parameters to be consistent
DoNotMock was removed from error_prone_annotations in 2.1.3, because
there was no enforcement mechanism (which is in google/error-prone#572).
Guava and Trust also depend on error_prone_annotations and are beginning
to use newer versions, so our usage of DoNotMock is causing diamond
dependency problems. This allows us to update to 2.2.0.
The annotations were useful internally; we're solving that in cl/205294089.
This mainly copies documentation from other places, like StreamObserver
and ClientCall, but does fix some missing important threading notes.
Fixes#3413
As discussed in #1914, we need CallCredentials and MoreCallCredentials
to be stable, but there's less of a strong need for the contents of
CallCredentials to be stable. We're willing to commit to the name,
without needing to commit to the plumbing.
This has a number of small benefits. First, it makes stack traces
easier to read. For example:
Old class names:
```
ServerCalls$1$1.class
ServerCalls$1.class
ServerCalls$2$1.class
ServerCalls$2.class
```
New class names:
```
ServerCalls$StreamingServerCallHandler.class
ServerCalls$StreamingServerCallHandler$StreamingServerCallListener.class
ServerCalls$UnaryServerCallHandler.class
ServerCalls$UnaryServerCallHandler$UnaryServerCallListener.class
```
This is much easier to read quickly, espcially if line numbers don't
match between HEAD and the code that prints the stack trace.
Another benefit of this is that it drops a class file from the jar
(`EmptyServerCallListener`).
Lastly, it makes it easier in the future to test, since the specific
class can be referenced from a test. Traditionally this class
hasn't been easy to test.
The current check in ServerCallImpl is theoretically unsafe (#3059). Move that check into the stub, and expand the unit tests to cover other interesting edge cases on the server side:
client sends one, but zero requests received at onHalfClose
client sends one, but > 1 requests received at onHalfClose
server sends one, but zero responses sent at onComplete
server sends one, but > 1 responses sent via onNext
fixes#2243fixes#3059
All that the `call` field was used for was to call `request` and nothing else. The `request` can be done by the `adapter` field, so the `call` field is redundant.
After debugging #2153, it would have been nice to know what the exact
parameter was that was null. This change adds a name for each
checkNotNull (and tries to normalized on static imports in order to
shorten lines)
780b2696 caused all failures for blocked unary stubs to have a
StatusRuntimeException as the cause of the StatusRuntimeException, with
the two exceptions having almost the same status.
It was withCallCredentials on the stub to avoid confusion with channel
credentials (which don't exist in Java at this time, but do in other
languages), and having the method names be different doesn't add value.
onReady/isReady previously could disagree causing a sort of deadlock
where the application isn't sending because grpc said not to, but won't
be informed to send via onReady later.
This is a stack trace from inprocessTransportOutboundFlowControl. The
line numbers are from this commit but with the changes to DelayedStream
disabled:
at io.grpc.internal.DelayedStream.isReady(DelayedStream.java:306)
(That is isReady returning false because fallThrough == false)
at io.grpc.internal.ClientCallImpl.isReady(ClientCallImpl.java:382)
at io.grpc.stub.ClientCalls$CallToStreamObserverAdapter.isReady(ClientCalls.java:289)
at io.grpc.stub.ClientCallsTest$8$1.run(ClientCallsTest.java:403)
(And yet that was the onReady callback, and it won't be called again)
at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onReady(ClientCalls.java:377)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$4.runInContext(ClientCallImpl.java:481)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:52)
at io.grpc.internal.SerializeReentrantCallsDirectExecutor.execute(SerializeReentrantCallsDirectExecutor.java:65)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.onReady(ClientCallImpl.java:478)
at io.grpc.internal.DelayedStream$DelayedStreamListener.onReady(DelayedStream.java:366)
at io.grpc.inprocess.InProcessTransport$InProcessStream$InProcessServerStream.request(InProcessTransport.java:284)
at io.grpc.internal.ServerCallImpl.request(ServerCallImpl.java:99)
at io.grpc.stub.ServerCalls$ServerCallStreamObserverImpl.request(ServerCalls.java:345)
at io.grpc.stub.ClientCallsTest.inprocessTransportOutboundFlowControl(ClientCallsTest.java:432)
Fixes#1932
This reverts commit 3df1446deb.
The commit was adding to the difficulty of integration for testing. By
itself it isn't bad, so this is a temporary revert until the many other
commits are absorbed and then it will be reapplied.
This does have a manual edit for ClientCallsTest.
The test has found a legitimate flake caused by a race in DelayedStream
related to onReady. Disable it until the fix arrives to prevent CI
failure noise.
If the timoutout expires, the test will almost certainly fail now due to
responses not matching expected responses, but it isn't as obvious why
the test fails. Swapping to ArrayList prints the entire list when they
don't match, which also makes it easier to diagnose.
This is, in part, to help diagnose #1932
Introduce CallCredentials as a first-class option to allow applications
to set per-call credentials into headers for outgoing RPCs. This will
supersede ClientAuthInterceptor. It has access to more
information (e.g., transport attributes, MethodDescriptor) and allow
results to be returned asynchronously, e.g., from a blocking I/O, which
was problemantic with ClientAuthInterceptor.
Eric Anderson
Ran
Jihun Cho
DRayX
Chengyuan Zhang
Roman Leventov
sanjaypujare
Carl Mastrangelo
Vladimir Gordiychuk
Nick Hill
Kun Zhang
Ze'ev Klapow
Venil Noronha
ST-DDT
ZHANG Dapeng
zpencer
jbingham-google
Grant Oakley
Ryan Michela
Mehrdad Afshari
nmittler
Louis Ryan
Kun Zhang
elandau