[
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
