From d98df2a8707ef29c427253bae3d7974f8d0528e3 Mon Sep 17 00:00:00 2001 From: kspoelstra Date: Fri, 14 Apr 2017 00:03:22 +0200 Subject: [PATCH] Fix for dropped connections due to next_inactivity_timeout_at==0 and inactivity_timeout_in!=0 Under certain conditions it is possible that read_disable or write_disable will set vc->next_inactivity_timeout to 0 while inactivity_timeout_in still has a value. In manage_active_queue this will lead to a close of the vc, resulting in interrupted service for the client. Checking the source code the best fix seems to be to check for next_inactivity_timeout_at!=0 in manage_active_queue. The value 0 does not seem to be used to force an early close/cleanup. The current time is used for that in certain cases. The active timeout does not have this problem. If it is set to 0 the active_timeout_in is also set to 0. This cannot be done for inactive timeout because the net_activity call needs inactivity_timeout_in. --- iocore/net/UnixNet.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/iocore/net/UnixNet.cc b/iocore/net/UnixNet.cc index 180acc8ba7f..1253521287b 100644 --- a/iocore/net/UnixNet.cc +++ b/iocore/net/UnixNet.cc @@ -587,7 +587,7 @@ NetHandler::manage_active_queue(bool ignore_queue_size = false) int total_idle_count = 0; for (; vc != NULL; vc = vc_next) { vc_next = vc->active_queue_link.next; - if ((vc->inactivity_timeout_in && vc->next_inactivity_timeout_at <= now) || + if ((vc->inactivity_timeout_in && vc->next_inactivity_timeout_at && vc->next_inactivity_timeout_at <= now) || (vc->active_timeout_in && vc->next_activity_timeout_at <= now)) { _close_vc(vc, now, handle_event, closed, total_idle_time, total_idle_count); }