[ https://issues.apache.org/jira/browse/THRIFT-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421225#comment-13421225 ]
Dominik Psenner commented on THRIFT-1653: ----------------------------------------- This timeout exists for cases where the remote peer crashes and may keep sending data to the socket. It effectively prevents that a port is being reused too early because that may result into the problem that it receives data from the earlier session in case that the remote peer suddenly manages to send packets or packets were routed oddly and travelled longer than expected. Therefore the decision of how long tcp_fin_timeout should be chosen depends mostly on the network infrastructure and should be lowered only to the worst case round trip time of a client. If your server resides in the USA and one client is in China, your worst case round trip time may be longer than 5 seconds. If all your clients are on a LAN, the worst case round trip time may be much shorter than a second. Connection pooling, on the other hand, improves the situation whenever there are only a few clients that query a service very frequently because a singlethreaded client will use at most one connection. In case when there are many clients it effectively worses the situation because it will keep connections open and lock down the server with idle connections. > TThreadedSelectorServer leaks CLOSE_WAIT sockets > ------------------------------------------------- > > Key: THRIFT-1653 > URL: https://issues.apache.org/jira/browse/THRIFT-1653 > Project: Thrift > Issue Type: Bug > Reporter: Mikhail Bautin > Assignee: Jake Farrell > Fix For: 0.9 > > > We are using TThreadedSelectorServer in HBase regionserver. We are observing > that under high load thousands of sockets in the CLOSE_WAIT state are not > being cleaned up, leading to server crash. Is it possible that the sockets > are not being closed on the server side, or the process of closing sockets > closed by client is being starved on the server, because normal I/O takes > priority? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira