From: Otto Moerbeek <otto.moerbeek@open-xchange.com>
Date: Wed, 9 Oct 2019 09:12:38 +0000 (+0200)
Subject: On read error we remove the fd from the set. If there are still queries in-flight
X-Git-Tag: dnsdist-1.4.0-rc4~8^2~4
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=3cabb7508fbb95c63b7efd9f9f1df020200c27ed;p=pdns

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 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 &) {
+            }
           }
         }
       }