You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "David Handermann (Jira)" <ji...@apache.org> on 2021/09/28 02:10:00 UTC
[jira] [Resolved] (NIFI-8079) DistributedMapCacheClient not
properly closing Sockets on connection failure
[ https://issues.apache.org/jira/browse/NIFI-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Handermann resolved NIFI-8079.
------------------------------------
Fix Version/s: 1.15.0
Resolution: Fixed
> 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
> Fix For: 1.15.0
>
>
> 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)