* 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
* Use WorkSerializer in XdsClient to propagate updates
* Fix breakage
* Add missing Drain
* More fixes
* Get around msvc issue
* Fix asan leak
* Reviewer comments
* Get around TSAN annotations
* Remove notes
* Clang-format
* Reviewer comments
By default the state is set to IDLE, which is not desired because
1. The actual connectivity state when transport is created is READY
2. The binder tansport channel won't be able to recover from IDLE state
for some reason and cause the channel to stuck when used on multiple
thread. We have an internal bug tracking this issue.
* 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
* Run 2to3 on tools directory
* Delete github_stats_tracking
* Re-run 2to3
* Remove unused script
* Remove unused script
* Remove unused line count utility
* Yapf. Isort
* Remove accidentally included file
* Migrate tools/distrib directory to python 3
* Remove unnecessary shebang
* Restore line_count directory
* Immediately convert subprocess.check_output output to string
* Take care of Python 2 shebangs
* Invoke scripts using a Python 3 interpreter
* Yapf. Isort
* Try installing Python 3 first
* See if we have any Python 3 versions installed
* Add Python 3.7 to Windows path
* Try adding a symlink
* Try to symlink differently
* Install six for Python 3
* Run run_interop_tests with python 3
* Try installing six in python3.7 explicitly
* Revert "Try installing six in python3.7 explicitly"
This reverts commit 2cf60d72f3.
* And debug some more
* Fix issue with jobset.py
* Add debug for CI failure
* Revert microbenchmark changes
* adding api_fuzzer changes
* adding api fuzzer changes
* updating some typos
* updating api_fuzzer and corpus entries
* updating api_fuzzer to fix crash due to two successive receive_op batches
* adding some reverted fixes to api_fuzzer.cc
* updating api_fuzzer and corpus as per initial comments
* fix some typos
* fix memory leaks and timeout issues
* adding some comments and removing debug strings
* updating api_fuzzer to remove previous edits to always add recv initial metadata ops for client calls
* updating passthru endpoint to account for erroneous initialization when channel effects are not simulated
* tidying up code
* Assert Android API >= v21
This precedes a change that would otherwise break on older Android APIs,
but in a more obvious way.
* error if __ANDROID_API__ is not defined
* update all Andriod minSdkVersions to 21
* csharp experimental: android-19 to 21
sanjaypujare
Craig Tiller
Ming-Chuan
Yash Tibrewal
AJ Heller
Mark D. Roth
Lidi Zheng
Richard Belleville
Jan Tattermusch
ZhenLian
Eric Anderson
Paulo Castello da Costa
Esun Kim
Vignesh Babu