[jira] [Commented] (HDFS-1965) IPCs done using block token-based tickets can't reuse connections

["Todd Lipcon (JIRA)" <ji...@apache.org>]

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

Todd Lipcon commented on HDFS-1965:
-----------------------------------

I can think of a couple possible solutions:

a) make the methods that operate on a block take an additional parameter to contain block tokens, rather than using the normal token selector mechanism that scopes credentials on a per-connection basis. This has the advantage that we can even re-use an IPC connection across different blocks.

b) when the client creates an IPC proxy to a DN, it can explicitly configure the maxIdleTime to 0 so that we don't leave connections hanging around after the call completes. This is less efficient than option A above, but it probably doesn't matter much for this use case.

> IPCs done using block token-based tickets can't reuse connections
> -----------------------------------------------------------------
>
>                 Key: HDFS-1965
>                 URL: https://issues.apache.org/jira/browse/HDFS-1965
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: security
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Critical
>             Fix For: 0.22.0
>
>
> This is the reason that TestFileConcurrentReaders has been failing a lot. Reproducing a comment from HDFS-1057:
> The test has a thread which continually re-opens the file which is being written to. Since the file's in the middle of being written, it makes an RPC to the DataNode in order to determine the visible length of the file. This RPC is authenticated using the block token which came back in the LocatedBlocks object as the security ticket.
> When this RPC hits the IPC layer, it looks at its existing connections and sees none that can be re-used, since the block token differs between the two requesters. Hence, it reconnects, and we end up with hundreds or thousands of IPC connections to the datanode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira