[
https://issues.apache.org/jira/browse/NIFI-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020706#comment-16020706
]
ASF GitHub Bot commented on NIFI-3732:
--------------------------------------
Github user ijokarumawak commented on the issue:
https://github.com/apache/nifi/pull/1842
I tested this using firewall to block/open port access against remote cache
server. Test details are available here in
[Gist](https://gist.github.com/ijokarumawak/9dcca0d82ce4af33f6e91b4728bc4f29).
It seems the communications timeout can not be configured longer than
default socket timeout (which is environment specific). But I think there is
not much for NiFi can do about that.
Overall, LGTM, +1. I'm going to merge this into master. Thank you @bbende !
> Distributed cache clients should use a timeout when opening a connection
> ------------------------------------------------------------------------
>
> Key: NIFI-3732
> URL: https://issues.apache.org/jira/browse/NIFI-3732
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.0.0, 1.1.0, 0.7.1, 1.1.1, 1.0.1
> Reporter: Bryan Bende
> Assignee: Bryan Bende
> Priority: Minor
> Fix For: 1.3.0
>
>
> The DistributedMapCacheClient and DistributedSetCacheClient open a socket
> connection using a CommsSession, either StandardCommsSession or
> SSLCommsSession.
> StandardCommsSession does the following to create a connection:
> {code}
> socketChannel = SocketChannel.open(new InetSocketAddress(hostname, port));
> socketChannel.configureBlocking(false);
> {code}
> The problem is that calling open() with the address calls connect before we
> have put the channel in non-blocking mode, so we could block indefinitely
> here.
> We should consider calling open(), then set a socket timeout from the timeout
> property in the cache client, and then call connect(address).
> The SSLCommsSession works slightly differently because it uses the
> SSLSocketChannel, but we should be able to do the same thing and pass in the
> SocketChannel after connecting as described above.
> In addition, the clients implement a close() method from the cache client
> interface, and its called from finalize(), but there should be an lifecycle
> method that calls close when the service is stopped.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)