This avoids the "changes" description, which could be understood to mean that
the transition is important instead of the steady-state and thus a callback
might not be called (which is not the case).
Much of the language was copied from ServerCall.
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
- Use gradle configuration `api` for dependencies that are part of grpc public api signatures.
- Replace deprecated gradle configurations `compile`, `testCompile`, `runtime` and `testRuntime`.
- With minimal change in dependencies: If we need dep X and Y to compile our code, and if X transitively depends on Y, then our build would still pass even if we only include X as `compile`/`implementation` dependency for our project. Ideally we should include both X and Y explicitly as `implementation` dependency for our project, but in this PR we don't add the missing Y if it is previously missing.
javax.annotation-api is licensed CDDL, which was not noticed when it was
introduced. Tomcat provides an Apache 2 version of the same annotation. Note
that this annotation is only used when compiling with Java 9+.
Unfortunately this may cause classpath collisions since there are _many_ copies
of this annotation on Maven Central; we wanted one canonical source and
javax.annotation-api seemed like that source. We hope this won't impact many
users since we have always suggested using it only for compilation. But it will
probably impact some users. However, we didn't create this mess, this seems to
be "standard practice" for J2EE, which this annotation is now part of, so we're
just impacted by it.
Fixes#6833
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
io.grpc has fewer dependencies than io.grpc.internal. Moving it to a
separate artifact lets users use the API without bringing in the deps.
If the library has an optional dependency on grpc, that can be quite
convenient.
We now version-pin both grpc-api and grpc-core, since both contain
internal APIs.
I had to change a few tests in grpc-api to avoid FakeClock. Moving
FakeClock to grpc-api was difficult because it uses
io.grpc.internal.TimeProvider, which can't be moved since it is a
production class. Having grpc-api's tests depend on grpc-core's test
classes would be weird and cause a circular dependincy. Having
grpc-api's tests depend on grpc-core is likely possible, but weird and
fairly unnecessary at this point. So instead I rewrote the tests to
avoid FakeClock.
Fixes#1447
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