* Revert "Revert "user-agent metadata trait, also: grpc_core::Slice is born (#27770)" (#28108)"
This reverts commit 89d08dad9d.
* will it blend
* will it blend
* will it blend
* lcnagfmt
* sanity
* will it blend
* sleep @ end
* will it blend
* Revert "sleep @ end"
This reverts commit d6bca8ed3d.
* review feedback
* review feedback
* Tooling to remove redundant grpc_core:: namespaces
These references tend to show up in our C++ code after C modules get
converted. Many get caught in review, many get missed.
* use it
* clang-format
* Check if memory owner available prior to polling it
The transport may drop the memory owner during its destruction sequence
* tcp_fix
* Revert "Revert "New resource quota integration (#27643)" (#28014)"
This reverts commit 0ea2c37263.
* clang-format
* fix-path
* fix
* Add failing end2end test for inconsistent percent-decoding of URIs
* Add passing h2_local_abstract_uds end2end tests
* Add basic abstract UDS example
* add test runner
* add proper bazel build path
* first attempt at CI configuration
* cleanup
* rename CI files for better readability
The authz test flaked as no RPCs of the expected type had completed
within the sampling window. Server logs showed authz logs completing
batch of 276 RPCs back-to-back, without the expected 40 ms separation
(qps=25). It took a bit over 1 second to process through the backlog.
With the sample duration of 500 ms and there being a polling delay
between when the channel is READY and when the test driver polls
channelz, it makes sense that we can get lucky much of the time.
Obviously, adding a sleep isn't great either, but measuring the queue
length indirectly is more complex than really appropriate here. The real
solution is to stop using this continuous-qps test client.
```
Traceback (most recent call last):
File "/tmp/work/grpc/tools/run_tests/xds_k8s_test_driver/tests/authz_test.py", line 252, in test_tls_allow
grpc.StatusCode.OK)
File "/tmp/work/grpc/tools/run_tests/xds_k8s_test_driver/tests/authz_test.py", line 183, in configure_and_assert
method=rpc_type)
File "/tmp/work/grpc/tools/run_tests/xds_k8s_test_driver/framework/xds_k8s_testcase.py", line 284, in assertRpcStatusCodes
self.assertGreater(stats.result[status_code.value[0]], 0)
AssertionError: 0 not greater than 0
```
* Rename the source files for ChannelArgsEndpointConfig
Previous naming was non-descript
* generate_projects
* add missing file to BUILD, and generate_projects.sh
* correct include guards
* Reintroduce the EventEngine default factory
An application can provide an EventEngine factory function that allows
gRPC internals to create EventEngines as needed. This factory would be
used when no EventEngine is provided for some given channel or server,
and where an EventEngine otherwise could not be provided by the
application. Note that there currently is no API to provide an
EventEngine per channel or per server.
I've also deleted some previous iterations on global EventEngine and
EventEngine factory ideas. This new code lives in a public API, and
coexists with iomgr instead of being isolated to an EventEngine-specific
iomgr implementation.
* add proper namespaces, and fix description
* put factory functions in their own file (for replaceability)
* add synchronization
* generate_projects.sh
* extract event_engine_base and event_engine_factory targets
Also separate iomgr/event_engine files in the BUILD, with comments
* gpr_platform
* move all EE factory declarations to event_engine_base
Makes internal hackery easier.
* add missing deps
* reorder dep alphabetically
* comment style change
Craig Tiller
Richard Belleville
Esun Kim
sanjaypujare
Yash Tibrewal
Paulo Castello da Costa
Zach Reyes
Terry Wilson
Jan Tattermusch
Hannah Shi
yifeizhuang
AJ Heller
Lidi Zheng
ZhenLian
Eric Anderson