-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Networking & Observability
-
Fully Compatible
-
ALL
-
v8.0, v7.0, v6.0
-
Networking & Obs 2025-01-06, Networking & Obs 2025-01-20
-
200
The following is how we currently handle interruptions during network reads:
do { size = asio::read(stream, buffers, ec); } while (ec == asio::error::interrupted); // retry syscall EINTR
The above assumes no data is read during unsuccessful, interrupted attempts. Therefore, bytes read before interruption will be overwritten by future read operations, and the read operation (i.e. opportunisticRead) will not successfully complete. The client will eventually timeout the operation and close the socket, triggering a failure on the server side and forcing the server to close its end of the connection.
The code should consider perviously received bytes and adjust the buffer, similar to what's done for the asynchronous reads:
if (((ec == asio::error::would_block) || (ec == asio::error::try_again)) && (_blockingMode == async)) { MutableBufferSequence asyncBuffers(buffers); if (size > 0) { asyncBuffers += size; } ... return asio::async_read(stream, asyncBuffers, UseFuture{}).ignoreValue(); } else { return futurize(ec); }
As part of this investigation, we should also make sure the write path properly handles interruptions, and if not, file a ticket to fix the writes as well.
- is depended on by
-
SERVER-98867 Re-enable config fuzzer EINTR/SIGUSR2 testing
- Blocked
-
SERVER-99001 Re-enable config fuzzer EINTR/SIGUSR2 testing on non-TLS variants
- Needs Scheduling
- is related to
-
SERVER-98592 Handle interruptions during TLS handshake
- Open