[
https://issues.apache.org/jira/browse/HDFS-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549011#comment-13549011
]
Suresh Srinivas commented on HDFS-4367:
---------------------------------------
bq. I don't think this should be considered an incompatible change since old
clients will in fact never request a DataEncryptionKey when data encryption
isn't enabled. i.e. a client will never request an encryption key from the NN
in a scenario where it's possible for the NN to return a null response.
Aaron, sorry I may not have understood the comment or this feature well. I
still think this is incompatible. Let me know if I understand this correctly.
This feature was introduced by HDFS-3637 in 2.0.2-alpha and works as follows:
# Server returns null if dfs.block.access.token.enable is false or
dfs.encrypt.data.transfer is false
# Client methods that use DFSClient#getDataEncryptionKey() check server
defaults and calls ClientProtocol#getDataEncryptionKey if
dfs.encrypt.data.transfer is set true
#* These calls hit null pointer exception, if on the server,
dfs.block.access.token.enable is false and dfs.encrypt.data.transfer is true.
When we fix server, this hits protobuf exception on the client side.
> GetDataEncryptionKeyResponseProto does not handle null response
> ----------------------------------------------------------------
>
> Key: HDFS-4367
> URL: https://issues.apache.org/jira/browse/HDFS-4367
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.0.2-alpha
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Priority: Blocker
> Attachments: HDFS-4367.patch
>
>
> GetDataEncryptionKeyResponseProto member dataEncryptionKey should be optional
> to handle null response.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
