| Age | Commit message (Collapse) | Author |
|---|
|
Add basic build files for the grpc-java modules.
Still need to be added: netty, protobuf
Test: make
Bug: None
Change-Id: I9248dd23c0ec24ec0f9a15aa6f6d826b7b90d617
|
|
|
|
|
|
This helps an internal cleanup removing the old failWithRawMessage API.
|
|
By adding inner class annotations without introducing external dependencies.
|
|
|
|
|
|
|
|
|
|
Due to transitive dependencies, this also upgrades Guava to 22. However
Truth is only used in our tests, so our users should be unimpacted.
|
|
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.
|
|
|
|
Found via ErrorProne
|
|
Found via ErrorProne
|
|
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.
|
|
remove unused fields from removed bloom filter
|
|
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 is the bloom filter based context improvement authored by @lukesandberg
|
|
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
7f1ac34d41d1f818d1702b25eefb5f6ef3423e69,
2f6e2c87ab1aeda591fcb7764a8ad6bb20855a2a,
a3a5420922ecf1ddc2c4ab77c273be3df47b74f5
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.
|
|
This is important for stable builds, as if the signature changes the old source
may no longer validate.
|
|
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
|
|
|
|
|
|
Also, update the authors.
|
|
all: Minor updates to expand javadocs
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
To make it easier to filter.
|
|
This is an alternative to #2543 and it doesn't introduce volatile usage.
|
|
|
|
http://errorprone.info/bugpattern/ClassNewInstance
|
|
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.
|
