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().

diff --git a/pdns/pdns_recursor.cc b/pdns/pdns_recursor.cc
index 99cc7273a8d875649925bad933e3c542fb1ede9b..636550cf361de4042f3bae5c517bf4b07a98dc8f 100644 (file)
--- 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 &) {
+            }
           }
         }
       }