Have added the required client, server, proto and proto generated files.
The design of the example is as follows:
1. The client sends a bulk amount of data(approx. 2 KB in each
iteration) to the server in a streaming call.
2. The server applies back-pressure by delaying reading of the requests,
which makes the client pause sending requests after around 64KB
3. The client then resumes sending requests only after the server reads
a few requests and clears the buffer.
By adding print statements on data send/receive on both client and
server side, the client pausing/resuming requests can be seen clearly.
The client and server logs can be seen below:
**Client Logs**
```
Request 10: Sent 20000 bytes in total
Request 20: Sent 40000 bytes in total
Request 30: Sent 60000 bytes in total
Request 40: Sent 80000 bytes in total
Received 10 responses
Request 50: Sent 100000 bytes in total
Received 20 responses
Request 60: Sent 120000 bytes in total
Received 30 responses
Request 70: Sent 140000 bytes in total
Received 40 responses
Request 80: Sent 160000 bytes in total
Received 50 responses
Request 90: Sent 180000 bytes in total
Received 60 responses
Request 100: Sent 200000 bytes in total
Received 70 responses
Received 80 responses
Received 90 responses
Received 100 responses
```
**Server Logs**
```
Server started, listening on 50051
Request 10: Received 20000 bytes in total
Request 10: Sent 20000 bytes in total
Request 20: Received 40000 bytes in total
Request 20: Sent 40000 bytes in total
Request 30: Received 60000 bytes in total
Request 30: Sent 60000 bytes in total
Request 40: Received 80000 bytes in total
Request 40: Sent 80000 bytes in total
Request 50: Received 100000 bytes in total
Request 50: Sent 100000 bytes in total
Request 60: Received 120000 bytes in total
Request 60: Sent 120000 bytes in total
Request 70: Received 140000 bytes in total
Request 70: Sent 140000 bytes in total
Request 80: Received 160000 bytes in total
Request 80: Sent 160000 bytes in total
Request 90: Received 180000 bytes in total
Request 90: Sent 180000 bytes in total
Request 100: Received 200000 bytes in total
Request 100: Sent 200000 bytes in total
```
This moves more code out of the monolithic `grpc_xds_client` BUILD target. We still need more work to split it up completely, but this is a nice step in the right direction -- and it unblocks a subsequent PR that I'm working on for xDS authority rewriting.
Closes#37130
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37130 from markdroth:xds_resource_type_build_refactoring a021d9773c
PiperOrigin-RevId: 648742472
[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#37053
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37053 from tanvi-jagtap:large_file_02 54224e3d63
PiperOrigin-RevId: 648565511
We can't actually test this until we change `WorkSerializer` to use `absl::AnyInvocable<>` and then implement `ClientChannel::AddConnectivityWatcher()`, but I wanted to get this in place so that it's ready when the time comes.
Closes#37099
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37099 from markdroth:client_channel_v3_external_connectivity_watch 745409c7a1
PiperOrigin-RevId: 648480028
Since these were disabled they stopped working, and we really need to be tracking overheads here.
Closes#37077
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37077 from ctiller:it-must-work aa19a4aa89
PiperOrigin-RevId: 648469428
<!--
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.
-->
Closes#37127
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37127 from yousukseung:extend-work-serializer-dispatch b63295336a
PiperOrigin-RevId: 648451105
1. fix some cases where we were missing opportunities to batch wakeups
2. eliminate recursion when switching parties post-batching (makes profiles significantly easier to read, saves a few cycles)
Closes#37072
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37072 from ctiller:rolling-party 9b56542b95
PiperOrigin-RevId: 648427987
[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#37093
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37093 from tanvi-jagtap:src_core_lib_misc 4c67a380e0
PiperOrigin-RevId: 648292698
[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#37092
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37092 from tanvi-jagtap:src_core_handshaker 297b2bd2cb
PiperOrigin-RevId: 647964631
[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#37090
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37090 from tanvi-jagtap:src_core_ext_transport_chaotic_good 5e709bce4f
PiperOrigin-RevId: 647960983
[Gpr_To_Absl_Logging] Reducing log spam because of complaints from user
Closes#37106
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37106 from tanvi-jagtap:reduce_verbosity 044c5aade1
PiperOrigin-RevId: 647905894
[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#37069
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37069 from tanvi-jagtap:src_core_lib_security a95b1b9543
PiperOrigin-RevId: 647857734
[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#37041
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37041 from tanvi-jagtap:src_core_ext_transport_binder aae32adf3c
PiperOrigin-RevId: 647853742
This allows CallTracers to be created with parameters dictated by
channel args.
For the moment, I've used the EventEngine `EndpointConfig` API to expose
the channel args here, so as to avoid directly exposing
`grpc_core::ChannelArgs`. We should determine a better API here before
we de-experimentalize the stats APIs.
Also add an experiment to be used in a subsequent PR.
PiperOrigin-RevId: 647730284
[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#37068
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37068 from tanvi-jagtap:src_core_ext_transport_binder_reduced 4f449b6563
PiperOrigin-RevId: 647559361
[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#37067
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37067 from tanvi-jagtap:src_core_lib_event 4ddf52b071
PiperOrigin-RevId: 647556953
Flaky tests are fixed now.
<!--
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.
-->
Closes#37061
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37061 from yousukseung:work-serializer-retry 610a8e0e1a
PiperOrigin-RevId: 647366412
Sreenithi Sridharan
Eugene Ostroukhov
Mark D. Roth
Tanvi Jagtap
Tanvi Jagtap
Yash Tibrewal
Craig Tiller
Vignesh Babu
Yousuk Seung
Esun Kim
Nana Pang
AJ Heller