I observed a case where `epoll_wait` would hang after receiving all available bytes (209 total). Note that all epoll events are configured to be edge-triggered (EPOLLET). The message was an HTTP request where the the HTTP headers indicated the connection would be closed. Presumably the peer would close their end of the connection, but the single epoll event did not contain EPOLLHUP. Regardless, the entire payload could be consumed in one read.
*Without* the TCP_INQ logic, the gRPC endpoint assumed that there was more data to read after the first read of 209 bytes. Since there was sufficient buffer space to read again, the endpoint called `recvmsg` a second time and immediately got EAGAIN. This triggered the downstream code to process the received data. Subsequent endpoint Reads would attempt a `recvmsg` first, and only if that failed, would then opt in to be notified of epoll events on their watched socket.
However, the INQ logic caused a nearly constant hang in this one environment, but non-deterministically. After a successful recvmsg (i.e., some bytes were received without any errors), INQ accurately showed there were no more bytes to read, and `recvmsg` was not called again, so the edge was never seen. The data was returned to the caller and the read was complete. The next endpoint Read would *first* ask to be notified of fd events, since the previous read claimed there was nothing left to read on that socket (this is the bug). Due to the nature of EPOLLET[1], the fd was very likely still in a ready state from the previous read, since it didn't call `recvmsg` until the edge was found. So the subsequent read was stuck waiting on a socket change event that may not come.
This fix resets the endpoint's state after consuming all available bytes according to TCP_INQ. This ensures that subsequent Reads will first attempt a read on the fd before requesting to be notified of new fd events.
[1]: https://www.man7.org/linux/man-pages/man7/epoll.7.html
> Receiving an event from epoll_wait(2) should suggest to you that such file descriptor is ready for the requested I/O operation. You must consider it ready until the next (nonblocking) read/write yields EAGAIN.
PiperOrigin-RevId: 666398394
Prior to this PR, the host and path were passed to the override functions, but the query params were unavailable to them. I have replaced the separate `host` and `path` parameters with a single parameter that passes the URI in as a const reference, which provides access to the query params.
While I was at it, I also changed the PUT and POST override methods to pass in the body as a string_view, which is more ergonomic for tests.
Closes#37540
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37540 from markdroth:httpcli_override_uri 902b0d2097
PiperOrigin-RevId: 665950188
Some applications cannot avoid the dependency on `//:grpc++_reflection` because it is buried by several infrastructural layers. For binaries that need to implement their own reflection server via generic handlers, this makes accepting request impossible as they will instead be handled by the default reflection server added by the server reflection plugin.
It would not be feasible to implement this as a build define because this binary is depended upon by many applications and buried beneath several layers of infrastructure.
Further, we cannot use the flag to control whether or not the plugin is installed as the plugin is installed at static initialization time, meaning that flags have not been parsed yet. Instead, we simply disable the functionality of the plugin with this flag.
CC @temawiCloses#37527
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37527 from gnossen:disable_cpp_reflection 8d7e32961a
PiperOrigin-RevId: 665051996
Extend Fuzzing timeouts to 1 year since the fuzzing EE caps delays passed to RunAfter to 1 year. This will prevent pre-mature timeouts of some legitimate fuzzed inputs.
Should fix b/358207194
PiperOrigin-RevId: 665012820
[Gpr_To_Absl_Logging] Remove gpr logging header from src/core headers.
Some of the cc files are using gpr_log_verbosity_init() functions.
So I removed the `#include <grpc/support/log.h>` from all headers and put it selectively only in the cc files that used gpr_log_verbosity_init()
Closes#37512
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37512 from tanvi-jagtap:remove_gpr_headers_from_headers a2f07f45d6
PiperOrigin-RevId: 664002265
[Gpr_To_Absl_Logging] Remove gpr logging header include from other headers
Some of the cc files are using gpr_log_verbosity_init() functions.
So I removed the #include <grpc/support/log.h> from all headers and put it selectively only in the cc files that used gpr_log_verbosity_init()
Closes#37513
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37513 from tanvi-jagtap:remove_gpr_headers_from_headers_01 612ca6d0f7
PiperOrigin-RevId: 663811895
[Gpr_To_Absl_Logging] Using GRPC_TRACE_LOG instead of GRPC_TRACE_FLAG_ENABLED
Closes#37516
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37516 from tanvi-jagtap:GRPC_TRACE_FLAG_ENABLED_09 c21f60f58a
PiperOrigin-RevId: 663811332
[Gpr_To_Absl_Logging] Fix use of GRPC_TRACE_FLAG_ENABLED in gen code
Closes#37514
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37514 from tanvi-jagtap:fix_gen_code_GRPC_TRACE_FLAG_ENABLED 096004c6d7
PiperOrigin-RevId: 663762507
[Gpr_To_Absl_Logging] Using GRPC_TRACE_LOG instead of GRPC_TRACE_FLAG_ENABLED
Closes#37483
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37483 from tanvi-jagtap:GRPC_TRACE_FLAG_ENABLED_08 ab8b98e8c4
PiperOrigin-RevId: 663618882
[Gpr_To_Absl_Logging] Using GRPC_TRACE_LOG instead of GRPC_TRACE_FLAG_ENABLED
Closes#37484
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37484 from tanvi-jagtap:GRPC_TRACE_FLAG_ENABLED_07 087d5fcfb3
PiperOrigin-RevId: 663606075
Mark D. Roth
gRPC Team Bot
AJ Heller
Eugene Ostroukhov
Esun Kim
Yash Tibrewal
Nathan Baulch
Evan Brown
Richard Belleville
Vignesh Babu
Tanvi Jagtap
Tanvi Jagtap
markdroth