[jira] [Commented] (NIFI-8079) DistributedMapCacheClient not properly closing Sockets on connection failure

["David Handermann (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17394756#comment-17394756 ] 

David Handermann commented on NIFI-8079:
----------------------------------------

Refactoring the Cache Clients to use Netty should incorporate resolving socket connection issues.

> DistributedMapCacheClient not properly closing Sockets on connection failure
> ----------------------------------------------------------------------------
>
>                 Key: NIFI-8079
>                 URL: https://issues.apache.org/jira/browse/NIFI-8079
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Extensions
>            Reporter: Mark Payne
>            Assignee: Mark Payne
>            Priority: Major
>
> The DistributedMapCacheClient doesn't always properly close Sockets if it fails to connect. Both the SSLCommsSession and the StandardCommsSession classes have something like this in the constructor:
> {code:java}
> socketChannel = SocketChannel.open();
> socketChannel.socket().connect(new InetSocketAddress(hostname, port), timeoutMillis);
>  {code}
> If the call to `socketChannel.socket().connect()` throws an Exception, the Socket may or may not be closed, depending on the reason for the failure. We need to ensure that in this case we properly call socketChannel.close().
> We should also check for any other spots where we may follow a similar pattern.
> This issue can be identified because the instance can run out of open file handles. Running `lsof -p <pid>` will show a lot of Socket file handles being used, but `netstat` won't show these because there's no established connection. The `ss` command will include these in the `closed` count.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)