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.
Carl Mastrangelo
Jakob Buchgraber
Eric Anderson
ZHANG Dapeng
nmittler
Kun Zhang
buchgr
Lukasz Strzalkowski
Łukasz Strzałkowski
Matt Hildebrand
Louis Ryan