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
This commit aligns the naming of the Bazel Maven jars with the names
used by Bazel's migration-tooling project:
https://github.com/bazelbuild/migration-tooling
Unfortunately, we can't fix @com_google_protobuf_java because it's
required by Bazel itself.
Fixes#3328
This API change allows storage implementations to put some state
information into the return value, giving it the ability to act
as a cookie. In environments where contexts can be replaced, the
current original context can be stashed there and be restored
when detach is called.
Use deadline on client calls lead to create TimeoutException even
if deadline not occurs yet. fillStacktrack very expensive operation
that allocate many unnecessary objects in heap. Now exception
creates only when deadline occurs.
Close#3272
This will break if
7f1ac34d41,
2f6e2c87ab,
a3a5420922
are reverted:
```
io.grpc.ContextTest > initContextWithCustomClassLoaderWithCustomLogger FAILED
java.lang.ExceptionInInitializerError
at io.grpc.ContextTest$LoadMeWithStaticTestingClassLoader.run(ContextTest.java:789)
at io.grpc.ContextTest.initContextWithCustomClassLoaderWithCustomLogger(ContextTest.java:760)
Caused by:
java.lang.RuntimeException: Storage override had failed to initialize
at io.grpc.Context.storage(Context.java:134)
at io.grpc.Context.current(Context.java:163)
at io.grpc.ContextTest$LoadMeWithStaticTestingClassLoader$1.publish(ContextTest.java:773)
at java.util.logging.Logger.log(Logger.java:738)
at java.util.logging.Logger.doLog(Logger.java:765)
at java.util.logging.Logger.log(Logger.java:875)
at io.grpc.Context.<clinit>(Context.java:122)
... 2 more
```
Using static initialization is possible, but quite complex to handle
logging and circular loading. Lazy loading prevents an entire class of
circular dependencies.
Turns out avoiding log() alone in the static initialization is not
enough. isLoggable() can also be overridden and call back to Context.
We take a another approach, save the exception and log it outside of
the initialization block.
Bazel third party dependencies are specified in repositories.bzl which
gives the consumer the ability to opt-out of any dependencies they use
directly in their own project.
Fixes#2756
Futures almost universally should be handled in some way when being
returned, either to receive the value or to cancel scheduled tasks to
prevent leaks.
Netty is a bit of a special case though, since it constantly returns
futures that you ignore (even adding a listener returns the "this"
future). So we want to suppress the warning for code using Netty instead
of trying to fix it. When we enable ErrorProne in the build, we should
start passing -Xep:FutureReturnValueIgnored:OFF in the compilerArgs.
The new plugin uses a newer version of animalsniffer, allows overriding
the animalsniffer version used, and has up-to-date handling. The
up-to-date handling cuts fully incremental parallel build times in half,
from 5.5s to 2.7s.
The previous plugin was supposed to be verifying tests. However, either
it wasn't verifying them or its verification was broken.
Currently Context propagate in-thread by its own ThreadLocal, and
cross-thread propagation must be done with the mechanisms provied by
gRPC Context. However, there are frameworks (e.g. what we are using
inside Google) which have already established context-propagation
mechanisms. If gRPC Context may ride on top of them, it would be
propagated automatically without additional effort from the application.
The Storage API allows gRPC Context to be attached to anything. The
default implementation still uses its own ThreadLocal. If an override
implementation is present, gRPC Context will use it.
The Context API is not particularly gRPC-specific, and will be used by
Census as its context propagation mechanism.
Removed all dependencies to make it easy for other libraries to depend
on.
Carl Mastrangelo