ServerImpl uses that ticker to create incoming Deadlines. This feature is specifically restricted to in-process, as it can also customize ScheduledExecutorService, and them together can fake out the clock which is useful in tests. On the other hand, a fake Ticker won't work with Netty's ScheduledExecutorService.
Also improved mismatch detection, documentation and tests in Deadline.
This makes Deadline more test-friendly. Next step is to allow
ServerBuilder to take a custom Ticker and use it for creating
incoming Deadlines. With both changes in, application logic will be
able to verify the Deadlines they set.
The `pendingDeadline` variable is modified from the ctor of CancellableContext, but it isn't final. The cancellation can happen before the variable is assigned. It's generally bad practice to leak the this reference from the ctor to other threads anyways.
This code refactors the deadline calculation and scheduling so that `pendingDeadline` is modified under the lock, and the `this` reference is not exposed.
Discovered by TSAN.
If you attach literal ROOT to the thread, if anyone else restores root
it will set the thread local to be null. This broke the "are you
detaching the current context" check, as ROOT != null. This was a
regression introduced in 55b08e67d.
The class is still used internally, so we move it to context's tests for
it to be reused. To avoid a circular dependency with context's tests
depending on core's tests, StaticTestingClassLoader was also moved to
context's tests.
This is driven by a need to modernize DeadlineSubject for newer versions
of Truth, but the newer versions of Truth update Guava. To avoid leaking
the Guava update to all users of grpc-testing, we're removing the
Subject. In our internal tests we can update the Truth dependency with
less issue.
If a context has an unreasonable number of ancestors, then
chances are this is an application error. Log the stack trace to
notify the user and aid in debugging.
The benchmarks should be close to the code they're benchmarking, like
we do with tests.
This includes a bugfix to SerializingExecutorBenchmark to let it run.
The io.grpc.benchmarks.netty benchmarks in benchmarks/ depend on
ByteBufOutputMarshaller from benchmarks's main, so they were not moved.
Now that we have the copy of write keyvalue store (#3368), there
is no need to keep the full parent chain. We only need a
reference to the nearest cancellable ancestor. This optimization
should in theory make cancellations more efficient and also make
our data structs more GC friendly.
This is the hashtrie data structure authored by @ejona86
The linked list key value store is known cause problems in
pathological cases where users keep updating the same key(s) over and
over. This copy on write tree will bound reads at O(lgN) where N is
the number of keys in the map, rather than O(lgM) where M is the total
number of put operations.
Also:
- added some unit tests
- ran a test putting random keys into the map and comparing the result
with a java.util.HashMap to verify sanity. The test passes but I
won't check it into the repo because it takes a long time to run:
https://gist.github.com/zpencer/12cb435235d171c1fe09aef18825fad0
Chengyuan Zhang
Nathan H. Leung
Eric Anderson
Aaditya Gavandalkar
ZHANG Dapeng
Kun Zhang
Carl Mastrangelo
Tim van der Lippe
Rodrigo Queiro
Eric Gribkoff
Bogdan Drutu
zpencer