У нас есть сервер, на котором запущен tomcat, и клиенты, использующие iphones. На iphone приложение использует ASIHTTPRequest в объединенной настройке (у меня нет деталей об этой части). Довольно часто сервер перестает отвечать на запросы, и при проверке netstat мы обнаруживаем, что в CLOSE_WAIT есть сотни соединений. Теперь я могу определить, что сервер ожидает отправки своего последнего ACK на телефон, но телефон больше не существует или не отвечает, поэтому соединения продолжают зависать, пока tomcat не будет перезапущен.
Я определил это, заметив 1 байт, оставленный в Recv-Q на сервере для каждого из этих подключений, а также из msdn: «На стороне, которая закрыла соединение, у вас будет FIN_WAIT_2, на стороне то есть для отправки окончательного FIN_ACK и ACK у вас будет CLOSE_WAIT. "
Ссылка: http://blogs.msdn.com/b/spike/archive/2008/10/09/tcp-connections-hanging-in-the-close-wait-and-fin-wait-2-state.aspx
Итак, мой вопрос, есть ли ошибка в ASIHTTPRequest, когда он закрывает соединение до того, как получает ACK? Или есть способ настроить Ubuntu для уничтожения этих соединений после X раз?
Дополнительная информация
Конфигурация соединителя Tomcat:
<Connector port="8080"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="3000"
connectionLinger="-1"
tcpNoDelay="true"
acceptCount="300"
maxThreads="400"
maxKeepAliveRequests="100"
redirectPort="8443"
/>
Опции sysctl:
kernel.printk = 4 4 1 7
fs.inotify.max_user_watches = 524288
fs.file-max = 13337
vm.mmap_min_addr = 65536
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_retries2 = 6
netstat ошибочного соединения:
root@example.com:~# netstat -an | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN
tcp 1 0 xx.xx.xx.xx:8080 xx.xx.xx.xx:49864 CLOSE_WAIT
IP удалены, чтобы защитить невинных
Обновление
Это немного странно, но я думаю, что должен добавить, что это происходит только тогда, когда наш код работает на slicehost. Запуск одного и того же «всего» на экземпляре Amazon EC2 не вызывает проблемы.