When a `std::multimap` has multiple entries with the same key, calling `m.find(key)` returns an unspecified element.
Historically, this returns the first matching element. However, this is not guaranteed, and recent libc++ changes make this return an arbitrary element.
Using `m.equal_range(key)` is a replacement that will preserve the current behavior. The behavior of this is guaranteed to return a range of all matching elements in insertion order, and the beginning of the range is the same element as what's normally returned by `m.find(key)`.
Closes#41279
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41279 from rupprecht:multimap-find 70b116441d03eff80523e010b25336f5a75c70c2
PiperOrigin-RevId: 852844558
This is needed for gRFC A105 (https://github.com/grpc/proposal/pull/516). Specifically, see the "Interaction with xDS Circuit Breaking" section.
It's possible for an LB pick to be happening at the same time as the subchannel sees its underlying connection fail. In this case, the picker can return a subchannel, but when the channel tries to start a call on the subchannel, the call creation fails, because there is no underlying connection. In that case, the channel will queue the pick, on the assumption that the LB policy will soon notice that the subchannel has been disconnected and return a new picker, at which point the queued pick will be re-attempted with that new picker.
When the picker returns a complete pick, it can optionally return a `SubchannelCallTracker` object that allows it to see when the subchannel call starts and ends. In the current API, when the channel successfully creates a call on the subchannel, it will immediately call `Start()`, and then when the subchannel call later ends, it will call `Finish()`. However, when the race condition described above occurs, the `SubchannelCallTracker` object will be destroyed without `Start()` or `Finish()` ever having been called. This API allows us to handle call counter incrementing and decrementing for things like xDS circuit breaking: we check the counter in the picker to see that it's currently below the limit, we increment the counter in `Start()`, and decrement it in `Finish()`. If the subchannel call never starts, then the counter never gets incremented.
With the introduction of connection scaling functionality in the subchannel, this approach will no longer work, because the call may be queued inside of the subchannel rather than being immediately started on a connection, and the channel can't tell if that is going to happen. In other words, there's no longer any benefit to the `Start()` method, because it will no longer actually indicate that the call is actually being started on a connection. As a result, I am removing that method from the API.
For xDS circuit breaking in the xds_cluster_impl LB policy, we are now incrementing the call counter in the picker, and the `SubchannelCallTracker` object will decrement it when either `Finish()` is called or when the object is destroyed, whichever comes first.
For grpclb, the `Start()` method was used in an ugly hack to handle ownership of the client stats object between the grpclb policy and the client load reporting filter. The LB policy passes a pointer to this object down to the filter via client initial metadata, which contains a raw pointer and does not hold a ref. To handle ownership, the LB policy returns a `SubchannelCallTracker` that holds a ref to the client stats object, but when `Start()` is called, it releases that ref, on the assumption that the client load reporting filter will subsequently take ownership. I've replaced this with a slightly cleaner approach whereby the call tracker always holds a ref to the client stats object, thus guaranteeing that the client stats object exists when the client load reporting filter sees it, and the client load reporting filter takes its own ref when it runs. (An even cleaner approach would be to instead pass the client stats object to the filter via a call attribute, similar to how we pass the xDS cluster name from the ConfigSelector to the LB policy tree, but it doesn't seem worth putting that much effort into grpclb at this point.)
Closes#41099
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41099 from markdroth:xds_circuit_breaking_counter_change eaa06bbdf1688c31c0d1e3b3cabe6a7d015fc075
PiperOrigin-RevId: 842261731
gRPC is currently getting formatted with two different clang-format implementations, and due to some weirdness they have different include file orderings. This change introduces clang-format configuration to ensure that the two systems align - it's *highly* expected that this will need some maintenance going forward as the two systems evolve.
Closes#40905
PiperOrigin-RevId: 819606209
See `grpc_check.h`. This code redefines the abseil `CHECK*` macros using custom gRPC macros when building tests. In `bazel test ...` builds, on check failure, `PostMortemEmit()` will dump state to the log before crashing.
Caveat: to prevent circular dependencies, code that `postmortem` relies on cannot use the custom gRPC CHECK macros. This is not much code, ~50 source files. grep for the `absl/log:check` bazel dependency.
Closes#39945
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/39945 from drfloob:grpc_check ca8e46718f2021e0df79aa67a3a0b0c751b3ce44
PiperOrigin-RevId: 807452496
[Copybara] Making includes uniform . This is for build layering
Closes#40388
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/40388 from tanvi-jagtap:ph2_settings bc30d3d013b0ac2b4f55e9040a2d2b8e25b42cdc
PiperOrigin-RevId: 791205698
We use builders for a variety of tasks - sometimes for testing, sometimes for adapting gRPC to novel environments, sometimes for once off special tasks early in a process lifetime.
Treating these as the same thing has started leading to some problems, so here I introduce a reset-proof registration for a subset of these tasks.
I'll be using this to register chaotic-good into the EndpointTransport registry so that it doesn't need to join the usual core configuration chain (and accidentally pull in protobuf to core).
PiperOrigin-RevId: 750048742
This moves files from various locations to their new home in src/core/call.
Closes#38888
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38888 from markdroth:reorg_call fec9f5b1b0cecf02726b235fb86416e857404ad3
PiperOrigin-RevId: 735853779
This includes the following moves from src/core/lib/security:
- certificate_provider/* → src/core/credentials/transport/tls/
- context/* → split between src/core/call/security_context* and src/core/transport/auth_context*
- credentials/
- composite/ → split between src/core/credentials/call/composite/ and src/core/credentials/transport/composite/
- alts, google_default, insecure, local, ssl, tls, xds → src/core/credentials/transport/
- fake/ → split between test/core/test_util/test_call_creds* and src/core/credentials/transport/fake
- external, iam, jwt, oauth2, plugin, token_fetcher → src/core/credentials/call/
- call_creds_utils.* → src/core/credentials/call/
- channel_creds_registry* → src/core/credentials/transport/
- credentials.* → split between src/core/credentials/call/call_credentials.* and src/core/credentials/transport/transport_credentials.*
- security_connector/
- alts, fake, insecure, local, ssl, tls → src/core/credentials/transport/
- security_connector* → src/core/credentials/transport/
- ssl_utils*, load_system_roots* → src/core/credentials/transport/tls/
- transport/ → src/core/filter/auth/
- util/* → src/core/credentials/call/
The only thing left in src/core/lib/security is the authz code, which I will move in a separate PR.
I have also moved the tests from test/core/security into a similar structure. Some specific notes:
- I have removed print_google_default_creds_token.cc, since it does not appear in any build file and appears to be completely unused.
- I moved secure_endpoint_test.cc to test/core/handshaker, to match where the implementation lives in the tree.
Closes#38825
PiperOrigin-RevId: 731487339
This almost certainly doesn't need the PRECISE clock type, and is the only call site to use it right now.
Once this is gone we can remove GPR_CLOCK_PRECISE, and then an entire timer subsystem that backs it.
Closes#38771
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38771 from ctiller:goonbag c7a5e3aa3115f966c3c6ae3aadbfb7804a47a931
PiperOrigin-RevId: 729155584
Maybe in some of these cases, `{}` would work instead of `std::pair`, but I'm just doing a simple find and replace here.
Closes#38636
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38636 from yashykt:NoMakePair d819f6a74be2fb2859083436297f79ed3139a1b7
PiperOrigin-RevId: 722772621
C++17 : Template argument deduction for class templates
Closes#38643
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38643 from pawbhard:cleanup-tuple dcd211ff5b824d2854c4de5e26e96d61619fa1b3
PiperOrigin-RevId: 721806200
This is only ever set to C++, so removing it from bazel.
There are remnants left in cmakefile generation that I'm not planning on cleaning up (looked like some of the yaml/python pieces still use this)
Closes#38501
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/38501 from ctiller:language c8aee06a01a449483b7585a367ff793fde47f68a
PiperOrigin-RevId: 718198572
Continuation of #37541 but focused on C++.
Closes#37755
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37755 from NathanBaulch:typos-cpp 9a7fd9d65fa97a689d529772534df1a501031e9f
PiperOrigin-RevId: 684600898
The following files have been moved:
- src/core/lib/avl/*
- src/core/lib/backoff/*
- src/core/lib/debug/event_log*
- src/core/lib/iomgr/gethostname*
- src/core/lib/iomgr/grpc_if_nametoindex*
- src/core/lib/matchers/*
- src/core/lib/uri/* (renamed from uri_parser.* to uri.*)
- src/core/lib/gprpp/* (existing src/core/util/time.cc was renamed to gpr_time.cc to avoid conflict)
Closes#36792
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36792 from markdroth:reorg_util d4e8996f481c611ffbb06a8b04924ff81bc1bc2b
PiperOrigin-RevId: 676947640
[Gpr_To_Absl_Logging] Remove logging header from example and test/cpp folder
Closes#37488
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37488 from tanvi-jagtap:remove_header_examples 1423ee77fff3136f3157993c07a5288552768e0d
PiperOrigin-RevId: 663597077
Previously, metadata mutations were made by the picker directly, which meant that they would be applied even if the channel winds up discarding the pick due to the returned subchannel having been disconnected by the time the pick result is returned. This changes the API such that pickers return metadata mutations along with the pick result, so that the mutations won't get applied unless the pick result is actually used.
Closes#36968
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36968 from markdroth:lb_metadata_api 2765da61214f3ae63da3fdb8e362fac625b51c5a
PiperOrigin-RevId: 645451869
[Gpr_To_Absl_Logging] Move function to test header form log.h
This is not really needed in log.h
Closes#36860
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36860 from tanvi-jagtap:move_function_to_test_header e6494bd06f2e4a08c91eb41f420607f9568b22ac
PiperOrigin-RevId: 642080756
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36678
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36678 from tanvi-jagtap:test_cpp_gpr_log 81b8f4179f6111b902cbed9eb65ef6f41eb1e32d
PiperOrigin-RevId: 636410944
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36636
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36636 from tanvi-jagtap:regex_test_cpp f2cac9c5a49f8d6025989160b9d9d6954dc8cc2d
PiperOrigin-RevId: 634954173
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - BUILD
In this CL we are just editing the build and bzl files to add dependencies.
This is done to prevent merge conflict and constantly having to re-make the make files using generate_projects.sh for each set of changes.
Closes#36607
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36607 from tanvi-jagtap:build_test_cpp 3e17d778d03272cd51da86baa38b67f77760735c
PiperOrigin-RevId: 633523097
