Noticed some inconsistencies in our keepalive configuration -
* Earlier, even if keepalive pings were disabled, we would be scheduling
keepalive pings at an interval of INT_MAX ms.
* We were not using `g_default_client_keepalive_permit_without_calls` /
`g_default_server_keepalive_permit_without_calls`. They are both false
by default but they can be overridden in
`grpc_chttp2_config_default_keepalive_args`.
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
We want writes to participate in event re-ordering, but it's unlikely
that we can sustain one byte per 500ms on all tests and keep them
passing (which is the degenerate case right now).
Tune write delays down to 50ms for the moment, though I expect we'll
want to talk about going lower.
omgwtfbbq
This test relies on WAIT_FOR_READY semantics, but we don't do that in
the proxy, so it got assigned the wrong suite.
Fix the suite, fix the flakes.
Also add some handy dandy logging to help figure this stuff out in the
future.
I can still make the old algorithm break and assign duplicate names on
my machine... make it a little more robust.
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
I've had local runs with a 10 second gap between creating the call and
issuing the first batch client side.
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
Fix fuzzer found bug b/286716972
Follows up on https://github.com/grpc/grpc/pull/33266 but gets the edge
case right of when there's a read queued before the peer closes - in
that case we weren't waking up the read.
I've got a hypothesis that we're losing isolation between test shards
right now for "some reason".
This is a change to reflect test sharding in the port distribution that
we use, in an attempt to alleviate that.
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
We should probably cap this so that our customers have a chance of
cloning the repository.
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
Here the recv message batch 103 was returning end of stream.
Per the reasoning in
https://github.com/grpc/proposal/blob/master/L104-core-ban-recv-with-send-status.md
Sending status is the final thing for a call on the server, so requiring
a recv message to complete when we've sent status is getting into at
best a gray area in out spec.
Add a strict ordering between that recv and the sending of status to
make a more deterministic test.
fixes b/286708835, b/286727273
Fix#33308
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
- Switched from yapf to black
- Reconfigure isort for black
- Resolve black/pylint idiosyncrasies
Note: I used `--experimental-string-processing` because black was
producing "implicit string concatenation", similar to what described
here: https://github.com/psf/black/issues/1837. While currently this
feature is experimental, it will be enabled by default:
https://github.com/psf/black/issues/2188. After running black with the
new string processing so that the generated code merges these `"hello" "
world"` strings concatenations, then I removed
`--experimental-string-processing` for stability, and regenerated the
code again.
To the reviewer: don't even try to open "Files Changed" tab 😄 It's
better to review commit-by-commit, and ignore `run black and isort`.
Also drop a few deadlines so that tests can run faster (where that's
safe)
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
Revert "Revert "[core] Add support for vsock transport"
(https://github.com/grpc/grpc/pull/33276)"
This reverts commit
c5ade3011a.
And fix the issue which broke the python build.
@markdroth@drfloob please review this PR. Thank you very much.
---------
Co-authored-by: AJ Heller <hork@google.com>
The approach of doing a recursive function call to expand the if checks
for known metadata names was tripping up an optimization clang has to
collapse that if/then tree into an optimized tree search over the set of
known strings. By unrolling that loop (with a code generator) we start
to present a pattern that clang *can* recognize, and hopefully get some
more stable and faster code generation as a benefit.
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
---------
Co-authored-by: ctiller <ctiller@users.noreply.github.com>
This had been intended to be 500ms for the first round, but
inadvertently got bumped up during some last minute investigations.
Tune it back down, let things settle out, and then see whether we want
to increase it or not.
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
Reverts grpc/grpc#33223. Breaks internal build.
```
work_stealing_thread_pool.cc:180:27: error: format specifies type 'double' but the argument has type 'gpr_cycle_counter' (aka 'long') [-Werror,-Wformat]
```
When I converted these tests there was an intent to use gtest failures
to see past an unexpected event/no event received error - however that
doesn't work out because our tests rely on the prior events happening.
What we got instead was misattributed failures, folks chasing wild
theories on uninitialized data, dogs and cats living together, mass
hysteria.
Let's just crash and see if it makes diagnosis actually easier.
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
We had an infinite recursion in our tracer parsing code... probably not
a biggy, but it was blocking the fuzzers so fixing.
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
<!--
If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the
appropriate
lang label.
-->
Craig Tiller
Eugene Ostroukhov
Yash Tibrewal
Ming-Chuan
Mark D. Roth
Sergii Tkachenko
Yousuk Seung
Yadong
apolcyn
AJ Heller