From 3cabb7508fbb95c63b7efd9f9f1df020200c27ed Mon Sep 17 00:00:00 2001 From: Otto Moerbeek Date: Wed, 9 Oct 2019 11:12:38 +0200 Subject: [PATCH] On read error we remove the fd from the set. If there are still queries in-flight we will add it back if the in-flight condition is true. This is not a real problem as the next handleTCPClientReadable() will take care. Add a comment to explain that. Also, setting the TTD might throw so handle that. We might need a forgiving variant of removeReadFD() and setReadTTD(). --- pdns/pdns_recursor.cc | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/pdns/pdns_recursor.cc b/pdns/pdns_recursor.cc index 99cc7273a..636550cf3 100644 --- a/pdns/pdns_recursor.cc +++ b/pdns/pdns_recursor.cc @@ -1780,11 +1780,19 @@ static void startDoResolve(void *p) Utility::gettimeofday(&g_now, 0); // needs to be updated struct timeval ttd = g_now; if (dc->d_tcpConnection->d_requestsInFlight == TCPConnection::s_maxInFlight - 1) { + // A read error might have happened. If we add the fd back, it will most likely error again. + // This is not a big issue, the next handleTCPClientReadable() will see another read error + // and take action. //cerr << "Reenabling " << dc->d_socket << ' ' << dc->d_tcpConnection->d_requestsInFlight << endl; ttd.tv_sec += g_tcpTimeout; t_fdm->addReadFD(dc->d_socket, handleRunningTCPQuestion, dc->d_tcpConnection, &ttd); } else { - t_fdm->setReadTTD(dc->d_socket, ttd, g_tcpTimeout); + // fd might have been removed by read error code, so expect an exception + try { + t_fdm->setReadTTD(dc->d_socket, ttd, g_tcpTimeout); + } + catch (FDMultiplexerException &) { + } } } } -- 2.40.0