[
https://issues.apache.org/jira/browse/HDFS-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132505#comment-15132505
]
James Clampffer commented on HDFS-9753:
---------------------------------------
Thanks for the feedback Bob.
bq. Should we shave a few cycles and prevent copying a Protobuf object (yuck!)
by taking a const reference to the block token rather than copying it there?
The connection implementation makes a copy in its constructor
Yes, good point. This was very quick fix and I wanted to copy by value just to
be sure I wasn't going to have a dangling reference. Looking at it again we
already do the same thing when we get a reference to a LocatedBlockProto in
FileHandleImpl::blocks_, and the TokenProto is just a field in the
LocatedBlockProto. I'll fix this.
bq. It might be a little cleaner to move fetching the block token closer to
where it is being used, especially since there is a condition to return in
between, which would render the block token copy/fetch irrelevant.
Agreed, I'm slightly embarrassed I submitted the patch without doing that in
the first place.
> libhdfs++: Client fails to pass TokenProto from LocatedBlockProto to server
> when reading a block
> -------------------------------------------------------------------------------------------------
>
> Key: HDFS-9753
> URL: https://issues.apache.org/jira/browse/HDFS-9753
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: James Clampffer
> Assignee: James Clampffer
> Attachments: HDFS-9753.HDFS-8707.000.patch
>
>
> FileHandleImpl::AsyncPreadSome is forgetting to pass the TokenProto from the
> ExtendedBlockProto to the DN when making a connection. On some clusters this
> causes the DN to error out when trying to deserialize because the
> TokenProto's required fields weren't filled in before serialization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
