[
https://issues.apache.org/jira/browse/HDFS-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419948#comment-16419948
]
Erik Krogen edited comment on HDFS-13331 at 3/29/18 11:47 PM:
--------------------------------------------------------------
One way to achieve it would be to make {{alignmentContext}} a ThreadLocal in
{{Client}}. This matches well with how other state is maintained within
{{Client}}. Then, before calling into the {{ClientProtocol}}, {{DFSClient}} can
set the proper {{alignmentContext}}. It can reset it after the call completes.
We could facilitate this by bundling it into a {{Closable}} so that it could be
done in a try-with-resource statement like:
{code:java}
try (Client.setAlignmentContext(alignmentContext)) {
namenode.doWhateverCall(...)
}
{code}
Where {{setAlignmentContext}} returns a {{Closable}} whose {{close}} method
sets the alignment context back to null (or whatever it was previously). This
requires the least changes outside of DFSClient, but feels kind of hacky.
Given the {{Client}} already maintains a map of {{ConnectionId}} ->
{{Connection}} mapping, it seems we could leverage this to achieve a cleaner
solution. It seems that really the place this reference should be stored is
within {{Connection}}, or maybe {{ConnectionId}} but that seems a little less
clean. The {{Connection}}s are created via {{Client#getConnection}}, which is
called by {{Client#call}} -> {{ProtobufRpcEngine#invoke}}, so we could have the
{{DFSClient}} pass in its {{alignmentContext}} when it creates its proxy. Any
thoughts on this approach? Sorry for not chiming in on the last JIRA, btw.
was (Author: xkrogen):
One way to achieve it would be to make {{alignmentContext}} a ThreadLocal in
{{Client}}. This matches well with how other state is maintained within
{{Client}}. Then, before calling into the {{ClientProtocol}}, {{DFSClient}} can
set the proper {{alignmentContext}}. It can (optionally?) reset it after the
call completes. We could facilitate this by bundling it into a {{Closable}} so
that it could be done in a try-with-resource statement like:
{code:java}
try (Client.setAlignmentContext(alignmentContext)) {
namenode.doWhateverCall(...)
}
{code}
This requires the least changes outside of DFSClient, but feels kind of hacky.
Given the {{Client}} already maintains a map of {{ConnectionId}} ->
{{Connection}} mapping, it seems we could leverage this to achieve a cleaner
solution. It seems that really the place this reference should be stored is
within {{Connection}}, or maybe {{ConnectionId}} but that seems a little less
clean. The {{Connection}}s are created via {{Client#getConnection}}, which is
called by {{Client#call}} -> {{ProtobufRpcEngine#invoke}}, so we could have the
{{DFSClient}} pass in its {{alignmentContext}} when it creates its proxy. Any
thoughts on this approach? Sorry for not chiming in on the last JIRA, btw.
> Add lastSeenStateId to RpcRequestHeader.
> ----------------------------------------
>
> Key: HDFS-13331
> URL: https://issues.apache.org/jira/browse/HDFS-13331
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Affects Versions: HDFS-12943
> Reporter: Plamen Jeliazkov
> Assignee: Plamen Jeliazkov
> Priority: Major
> Attachments: HDFS-13331-HDFS-12943.002.patch,
> HDFS-13331-HDFS-12943.003..patch, HDFS-13331.trunk.001.patch,
> HDFS_13331.trunk.000.patch
>
>
> HDFS-12977 added a stateId into the RpcResponseHeader which is returned by
> NameNode and stored by DFSClient.
> This JIRA is to followup on that work and have the DFSClient send their
> stored "lastSeenStateId" in the RpcRequestHeader so that ObserverNodes can
> then compare with their own and act accordingly.
> This JIRA work focuses on just the part of making DFSClient send their state
> through RpcRequestHeader.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
