rec: Watch the descriptor again after an out-of-order read timeout

It might be that there was no other incoming query on that connection
and we timed out while the response had not been sent yet, but the
client might want to re-use the connection after receving the response.
We try to reset the TTD, but that might fail when the socket descriptor
has already been removed.

(cherry picked from commit b05ef1b472cfa3597dda44075f3947abd565008b)

diff --git a/pdns/pdns_recursor.cc b/pdns/pdns_recursor.cc
index e6fa7e4698d0d8af4cfba2ef9dc82429170d1f71..94b10d7151b2070b3de15845af3b106a9c68ecff 100644 (file)
--- a/pdns/pdns_recursor.cc
+++ b/pdns/pdns_recursor.cc
@@ -1815,11 +1815,15 @@ static void startDoResolve(void *p)
             ttd.tv_sec += g_tcpTimeout;
             t_fdm->addReadFD(dc->d_socket, handleRunningTCPQuestion, dc->d_tcpConnection, &ttd);
           } else {
-            // fd might have been removed by read error code, so expect an exception
+            // fd might have been removed by read error code, or a read timeout, so expect an exception
             try {
               t_fdm->setReadTTD(dc->d_socket, ttd, g_tcpTimeout);
             }
-            catch (FDMultiplexerException &) {
+            catch (const FDMultiplexerException &) {
+              // but the FD was removed because of a timeout while we were sending a response,
+              // we need to re-arm it. If it was an error it will error again.
+              ttd.tv_sec += g_tcpTimeout;
+              t_fdm->addReadFD(dc->d_socket, handleRunningTCPQuestion, dc->d_tcpConnection, &ttd);
             }
           }
         }