This change updates the behavior of the core compression semantics. Previously,
if the codec was "identity", nothing was set on the wire. This is allowed by
the spec, but doesn't match what wrapped languages do.
Additionally, the interop tests will now attempt to honor the requested
compression.
Without the warm up I saw large deltas, like 2,262,968ns and
1,712,558ns, on my machine. With the single-line warm up the deltas
decreased dramitically, like 385ns and 536ns. Since our times are so
much better now, decreasing the required delta to 10ms seems reasonable.
This would seem to support the theory that the flakiness was caused by
the class loader, which may even be doing I/O.
Fixes#1646
This reverts commit 8825f355df.
The commit changed the package name of services that were used across
languages. That broke their functionality pretty severely. The changes
require more coordination with others.
As of the discussion in #1584, the client does not
support TLS and interop tests that require auth are
yet to be implemented.
It has the same functionality as the C++ stress test client.
A call's timeout as specified in its metadata should be set depending
on the deadline of the call's context. If a call has an explicit deadline
set (through CallOptions), then the smaller deadline (from context and call options)
should be used to compute the timeout.
Also, a new method Contexts.statusFromCancelled(Context) was introduced that attempts
to map a canceled context to a gRPC status.
- Made CallOptions use the Deadline type instead of a
long to represent a deadline.
- Added new methods CallOptions.withDeadline(Deadline) and
AbstractStub.withDeadline(Deadline). The methods are
marked experimental, as the Deadline class is marked
experimental. These methods are meant to replace
CallOptions.withDeadlineNanoTime(Long) and
AbstractStub.withDeadlineNanoTime(Long), which have
been deprecated.
- Updated CallOptions.toString() to include all fields.
There are two AbstractTransportTests. The newest one is the more aptly
named, so rename the older one to AbstractInteropTest to remove name
collision when speaking.
Fixes#1484
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.
When triggered, it caused the ClientCall.Listener never to complete.
Fixes#1343
The new test doesn't actually fail on my machine with the old code, but
we would hope it would be flaky. Since a race is involved, I don't
expect a more reliable test.
The client didn't have the trust manager set, so the RPC would fail due
to server-certificate verification, not lack of client auth.
With this change, noClientAuthFailure now fails with tcnative but still
passes with Jetty ALPN.
basicClientServerIntegrationTest seems to be working for me, so I'm
enabling it.
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 reverts commit eca1f7c1d6.
We want to preserve the status message identical to what the server
sent. We'll need a better way to communicate debugging details.
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
Using a JWT is a bit more work than it should be, but improving that
will come later.
At present, this test fails, but it is believed to be due to the auth
library.
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}
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.
Many of the interop tests were designed with the default 64 KB flow
control window in mind. If we test with 1 MB then it defeats the flow
control testing.
65 KB is an arbitrary number, but I chose it to be rather small, but
still not the HTTP/2-default 64 KB because implementations have had
trouble with applying flow control changes correctly.
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.
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.
On my machine, the client currently takes ~3s to run a test. However,
with exit() it takes < 1s. When doing lots of integration tests, those
seconds add up.
We know one of those seconds is the DESTROY_DELAY_SECONDS of
SharedResourceHolder. Part of another second appears to be Netty
creating any threads that weren't previously created when shutting down.
1. Move DEFAULT_CONNECTION_SPEC to OkHttpChannelBuilder
2. make OkHttpClientTransport package-private
3. Rename OkHttpChannelBuilder.setConnectionSpec to connectionSpec
GCM is very slow, and doesn't provide any benefit in unit tests. Even if
we were using tcnative and GCM is fast, using more available ciphers in
tests still makes sense. With this change building with Java 7 works
again, although that isn't the reason for the change.
On my machine with parallel building, it cuts full build time from
92 seconds to 39 seconds. For an incremental build after only changing
an interop test, the build time is cut from 73 seconds to 15 seconds.
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*
To use the test certs a module has to depend on the grpc-interop-testing module, which doesn't really make sense. I'm moving the certs to the grpc-testing module, which is meant to be a sort of testing common area for all of our modules.
"Interoperability" is a more appropriate name for the tests, since they
are used for testing across different implementations. They will do a
bit of integration testing, like for auth, but this is a smaller scale.
It seems the other languages (Go, C++, Node, PHP, Python, Ruby) are
using "interop" to describe the tests, and the test case specifications
document is named with "interop". After this change, C# will be the only
language calling them "integration" tests.
This change just renames the folder and artifact. We can change the
internal package names later. However, once we do a release, old
artifact names will live forever in Maven Central.