[
https://issues.apache.org/jira/browse/THRIFT-4230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16289893#comment-16289893
]
Chet Murthy commented on THRIFT-4230:
-------------------------------------
two questions:
(1) Is there any sort of reasonably runnable reproduction? To wit, if it's as
simple as what's described, then perhaps there should be a simple way to
reproduce it without all the baggage of Hbase?
(2) are there any javacores, or any other stuff available? output of lsof?
netstat -an? anything else?
--> e.g. to distinguish between "Java thinks there are sockets, but there
aren't" and "there really are sockets hanging out forever"
(3) It sounds like the test scenario was one where client connections were
dropped using route/iptables, hence, NOT by killing the client? If instead you
kill the client, does the problem still occur? That is, is the "network-level
fault" intrinsic to the fault-scenario?
(4) Did you try to enable SO_KEEPALIVE in Java (by whatever means that happens
-- haven't programmed in Java in eons, so forget how it works)?
> Thrift server connection may hang forever
> -----------------------------------------
>
> Key: THRIFT-4230
> URL: https://issues.apache.org/jira/browse/THRIFT-4230
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
> Environment: OS: RHEL 7.2
> Reporter: Egor Kromberg
>
> After a lot of tests with HBASE Thrift server we found a problem.
> If the connection is dropped on the client side (using route or iptables) it
> may be still opened on the Thrift server side. Such situation will occur in
> case of unstable connection.
> After several iterations the Thrift server application will have a lot of
> opened connections and *will not accept *any new one. The only WA found is to
> restart the Thrift server.
> I believe Thrift server should have something like socket timeouts and
> heartbeats.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
