io.netty.util.Version is unreliable, so we stop using it. grpc-netty and
grpc-netty-shaded have their version.properties mix, and you can't tell
which is which.
Changed the tests to use assume, so it is clear in the results that they
weren't run.
This had been accidentally left in 0c179e3f9.
Requesting a refresh is pretty close to RetryingNameResolver's behavior
of exponential backoff. While not identical, it is the closest we can
get easily.
In the olden days Alpine didn't work at all. Then it worked. And then
sometime in 2021 it started failing (#8751) because of missing
__strndup. The most recent deep investigation showed it is missing
__strdup these days
https://github.com/grpc/grpc-java/issues/11660#issuecomment-2469284111 .
I'm not expecting too many people to find this themselves, but we can
link to it when they experience problems.
There's no reason why we shouldn't just have proper synchronization
here, even if only used in tests. We shouldn't get into the habit of
suppressing them.
Currently there is a race between 2 tasks scheduled to handle request
timeout
* servlet AsyncContext timeout
* gRPC Context
which can cause instability. This change makes the gRPC Context timeout happen first.
Follow up to PR #10563
Previously, we disabled Huffman encoding on the `NettyClientHandler` to
improve header encoding performance. This change also ensures
consistency in the header encoding strategy across both client and
server components.
Generated gRPC method names in the BlockingV2Stub can conflict with
final methods on `java.lang.Object` (e.g., `toString()`, `hashCode()`)
for client-streaming and bidi-streaming RPCs. This occurs because
they are generated with no arguments, leading to a compilation error.
One such case in #12331.
This change introduces a dedicated list of no-argument method names
from java.lang.Object and applies name-mangling (appending an
underscore) only when generating these specific methods in the
v2 blocking stub.
This resolves the compilation failure while ensuring that the behavior
for all other stubs remains unchanged.
Fixes: #12331
f8700a1 stopped using the dependency in our generated code and removed
the dependency the Bazel build. 4f6948f removed mention of the
dependency in our README. This deletes it from our Gradle build and the
examples.
Guava seems to call a deprecated sun.misc.Unsafe::objectFieldOffset
method which might be removed in a future JDK release.
There are still a few things to do for -android versions, which are
tracked in https://github.com/google/guava/issues/7742,
see details at google/guava#7811
Fixes#12215
With the default @generated=omit option used by grpc-compiler, it is no longer necessary to have the compile-only dependency on org.apache.tomcat:annotations-api.
It's discouraged in modern Bazel to use native rules and will make it
difficult for modules dependent on grpc-java to fully migrate to new
versions of Bazel (like grpc-kotlin).
For example, try building this repo using:
```bash
$ bazelisk build ... --incompatible_autoload_externally=
```
It will fail.
**IMPORTANT**: Now you still see errors after this commit, but it's
better because the errors come from `@protobuf`, not `@grpc-java`.
createContextAsUser() wrapper makes the call to PackageManager's
resolveService() look the same in both the same-user and cross-user
cases. This is how the Android team recommends accessing XXXAsUser() APIs in
general.
We can also remove all the apologies for using reflection since
SystemApis already explains all that.
It's pretty annoying to see a test failure with
"expected:<DEADLINE_EXCEEDED> but was:<INTERNAL>" and not know the
description or throwable cause of the status. Introduce a convenience to
include the full status on unexpected Status.Code. There were two
usages of assertWithMessage() that did give nice errors; those were
converted to this new utility.
It'd be even better to make a StatusSubject, but that'd take more time
and this was easy and still an improvement. This was created because
we're seeing servlet test failures with INTERNAL code, and we need to
see the details.
`attributes = setSecurityAttrs(attributes, remoteUid);` should not run
for :
- a malformed SETUP_TRANSPORT transaction
- a rogue SETUP_TRANSPORT transaction that arrives
post-TransportState.SETUP
Modifying existing Attributes was virtually guaranteed to allocate
within build(), just because `base` was not considered for the new map
size. Discard was also allocation-heavy because it often created a new
map. Using a regular copy-on-write approach is enough to avoid the
unnecessary allocations in both cases.
This was noticed in a profile that included xds's
AddressFilter.setPathFilter(), where Attributes.Builder.build()
allocated 6x the memory of Attributes.Builder.data().
b/435208946#comment41
Non-experts don't really know what these ServiceConnection callback
names mean (eg b/437170499). Use the Status description to explain them
a bit. Compare to https://github.com/grpc/grpc-java/pull/11628
Seems like previously it was not testing all the flows but only: the
write/flush calls are added to the queue by `runOrBuffer` because
`readyAndDrained` is initially `false`.
So,
* `isReady()` is never called
* `isReadyReturnedFalse` never set to true
* `maybeOnWritePossible()` does nothing
All that makes me think that #9917 is caused by some bugs in older
versions of llincheck, can be closed now.
A more real simulation happens if calling `onWritePossible` first via
`initialOnWritePossible`, and then it has found a race condition in
`AsyncServletOutputStreamWriterConcurrencyTest.isReady()`, if
`maybeOnWritePossible()` is executed before `return isReady`.
Additionally updated lincheck,
* it does not need jvmArgs now
* is compatible with java 8 again
* changed asserts from Truth to junit, as lincheck was trying to use
`com.google.common.truth.Subject.equals(Object)`
It still does not detect #12268, but might be needs more time.
Currently `AsyncContext.complete()` is called multiple times in some
flows, e.g. when DEADLINE_EXCEEDED, and that results in
IllegalStateException from servlet container (Tomcat).
If counting IllegalStateException from the tests of the servlet module
here - the number of those is reduced significantly, a few cases still
left, would bet addressed separately.
Just an is a8de9f0, lack of equals causes cluster_resolver to consider every update a different configuration and restart itself.
Handling NaN should really be prevented with validation, but it looks like that
would lead to yak shaving at the moment.
b/435208946
Since c4256add4 we no longer fabricate a TRANSIENT_FAILURE update from
children. However, previously that would have set
seenReadyOrIdleSinceTransientFailure = false and prevented future timer
creation. If a LB policy gives extraneous updates with state CONNECTING,
then it was possible to re-create failOverTimer which would then wait
the 10 seconds for the child to finish CONNECTING. We only want to give
the child one opportunity after transitioning out of READY/IDLE.
https://github.com/grpc/proposal/pull/509
Http2RstCounterEncoder has to be constructed before
NettyServerHandler/Http2ConnectionHandler so it must be static. Thus the
code/counters were moved into RstStreamCounter which then can be
constructed earlier and shared.
This depends on Netty 4.1.124 for a bug fix to actually call the
encoder:
be53dc3c9a
This implicitly disables NettyAdaptiveCumulator (#11284), which can have a
performance impact. We delayed upgrading Netty to give time to rework
the optimization, but we've gone too long already without upgrading
which causes problems for vulnerability tracking.
Abhishek Agrawal