The control plane was updated to more properly match the principal being
present, so now plaintext and mTLS are working properly. But the change
is using slightly the wrong semantics for TLS, so we get to change which
tests are commented out.
* Move most py_proto_library macro contents into rule.
The _generate_pb2_src rule is modified to produce a valid PyInfo
provider that can be depended on directly by py_.* rules.
Keeping an intermediate macro in place increases complexity without
adding any real value.
* Move most py_grpc_library macro contents into rule.
The _generate_pb2_grpc_src rule is modified to produce a valid PyInfo
provider that can be depended on directly by py_.* rules.
Keeping an intermediate macro in place increase complexity without
adding any real value.
* Remove support for additional plugins.
It's easy enough for a plugin author to build their own rule-set, and it
adds extra unused (and untested) complexity to gRPC's rules.
* Rewrite py_proto_library to track dependencies correctly.
* Propagate Python dependencies of py_grpc_library rules to consumers.
* Add test coverage for aspect-based py_proto_library.
This commit is part of the effort to create binder channel with
GRPC_CLIENT_CHANNEL type.
The resolver will be used during name resolution, and the result will
later be used to identify the corresponding endpoint binder in
SubchannelConnector.
Besides the unit test, this change is tested with other changes locally
end to end on real device.
* Wait for in-flight requests to complete during shutdown
This fixes a race condition between AllocatingRequestMatcherBase::MatchOrQueue()
implementations and ShutdownAndNotify(). In MatchOrQueue(), the server may
shutdown and delete the completion queue right after the shutdown check but
before the batch call allocation, resulting in a use-after-free case.
To fix, once the shutdown ref is unrefed and no new requests are accepted, the
server can wait for all requests in-flight at the moment to complete. The last
request that unrefs the shutdown ref unblocks the shutdown.
* Add must-use-value and locks-required annotations
* initial attempts to speedup qps tests
* make json_run_localhost finish without up to 5 sec lag
* cap number of client channels for qps tests
* regenerate bazel qps scenarios
* add a todo for driver.cc
* adjust max channel count for streaming_from_server
* regenerate scenarios
The pool serves as a buffer for interaction between C++ and Java.
The buffer can let us avoid calling into Java code in channel connector
implementation (which has not been merged yet), simplifies interaction
between C++ and Java.
Temporary changes are made to channel_create.cc to keep the example apps
working but they will be rewrite after we start creating client channel
instead of direct channel.
* ruby: use squiggly heredoc for rake-compiler-dock commands
* ruby: use `bundler exec` when building native gems
* ruby: clean .{bundle,so} from src/ruby/lib when building native gems
Failing to remove these files between native builds leads
rake-compiler to establish circular dependencies (which may be a bug
in rake-compiler, but this feels like an easy and good thing to do,
anyway).
* ruby: extract linux and darwin RUBY_PLATFORM checks into variables
There were already "windows" and "bsd" flags, so let's improve
consistency and readability, and set a clear pattern for subsequent
flags.
* ruby: rely on rake-compiler-dock v1.1.0 to set no_native correctly
As of v1.1.0 there's no need to set this explicitly anymore; it will
be true whenever the extension is being built in a RCD container.
See https://github.com/rake-compiler/rake-compiler-dock/commit/362890d
* ruby: add "x86_64-darwin" platform gem
Using RCD for this platform unifies the Darwin native gem build
process with the Linux native gems, which should help avoid
inconsistencies in packaging that result in issues like the missing
Ruby 3.0 binaries in #25060.
Please note that this change leaves the "universal-darwin" platform
native gem untouched, but provides a path forward if the project ever
decides to drop "universal" binary support.
Related to:
- #25429
- #25756
* Don't leave pending tasks on the asyncio queue
The results of these pending tasks are not needed, leaving them
on the queue grows the size of the queue until the call completes.
This fix slows the growth of the memory in the test example.
* Address 'leaking' Futures from cygrpc
Cancelling unneeded Tasks is not sufficient as this leaves behind
cancelled Futures in the cygrpc layer, which still occupy memory.
Instead, avoid creating unneeded tasks in the first place.
* Address review comments
1. Ignore unused return values
2. Fix formatting