You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2010/01/13 04:17:54 UTC
[jira] Created: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
DatanodeID.ipcPort is not updated when existing node re-registers
-----------------------------------------------------------------
Key: HDFS-894
URL: https://issues.apache.org/jira/browse/HDFS-894
Project: Hadoop HDFS
Issue Type: Bug
Affects Versions: 0.20.1, 0.21.0, 0.22.0
Reporter: Todd Lipcon
Priority: Blocker
In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830309#action_12830309 ]
Todd Lipcon commented on HDFS-894:
----------------------------------
Filed HDFS-953 for the testpatch failure seen above.
I think this is ready to commit.
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated HDFS-894:
-----------------------------
Component/s: name-node
This should be fixed in all three current branches. As mentioned in the description, it can prevent the write pipeline from recovering since ClientDatanodeProtocol and InterDatanodeProtocol won't be able to connect.
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon reassigned HDFS-894:
--------------------------------
Assignee: Todd Lipcon
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853974#action_12853974 ]
Hudson commented on HDFS-894:
-----------------------------
Integrated in Hadoop-Hdfs-trunk #275 (See [http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk/275/])
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Fix For: 0.22.0
>
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828887#action_12828887 ]
Hadoop QA commented on HDFS-894:
--------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12434614/hdfs-894.txt
against trunk revision 905760.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 2 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
-1 core tests. The patch failed core unit tests.
-1 contrib tests. The patch failed contrib unit tests.
Test results: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h2.grid.sp2.yahoo.net/111/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h2.grid.sp2.yahoo.net/111/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h2.grid.sp2.yahoo.net/111/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h2.grid.sp2.yahoo.net/111/console
This message is automatically generated.
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom White updated HDFS-894:
---------------------------
Fix Version/s: 0.22.0
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Fix For: 0.22.0
>
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom White updated HDFS-894:
---------------------------
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch Available)
I've just committed this. Thanks Todd!
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Tom White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831311#action_12831311 ]
Tom White commented on HDFS-894:
--------------------------------
+1
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853673#action_12853673 ]
Hudson commented on HDFS-894:
-----------------------------
Integrated in Hdfs-Patch-h2.grid.sp2.yahoo.net #146 (See [http://hudson.zones.apache.org/hudson/job/Hdfs-Patch-h2.grid.sp2.yahoo.net/146/])
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Fix For: 0.22.0
>
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834791#action_12834791 ]
Hudson commented on HDFS-894:
-----------------------------
Integrated in Hadoop-Hdfs-trunk-Commit #193 (See [http://hudson.zones.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/193/])
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Fix For: 0.22.0
>
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "dhruba borthakur (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831730#action_12831730 ]
dhruba borthakur commented on HDFS-894:
---------------------------------------
The code looks good. But since this is not a regression (and datanodes typically re-register with the same ipcPort) can we put this patch only in trunk?
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828892#action_12828892 ]
Todd Lipcon commented on HDFS-894:
----------------------------------
Failed test seems unrelated.
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated HDFS-894:
-----------------------------
Status: Patch Available (was: Open)
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831732#action_12831732 ]
Todd Lipcon commented on HDFS-894:
----------------------------------
bq. datanodes typically re-register with the same ipcPort
Unless you've configured the datanode IPC port to 0 - I do this on my test clusters on shared hardware, for example.
bq. this is not a regression
true enough. I find it an obvious enough bug that causes big problems when binding to port 0, that we should put it in all branches. But if you disagree, trunk's fine.
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HDFS-894) DatanodeID.ipcPort is not updated when
existing node re-registers
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated HDFS-894:
-----------------------------
Attachment: hdfs-894.txt
> DatanodeID.ipcPort is not updated when existing node re-registers
> -----------------------------------------------------------------
>
> Key: HDFS-894
> URL: https://issues.apache.org/jira/browse/HDFS-894
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 0.20.1, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Priority: Blocker
> Attachments: hdfs-894.txt
>
>
> In FSNamesystem.registerDatanode, it checks if a registering node is a reregistration of an old one based on storage ID. If so, it simply updates the old one with the new registration info. However, the new ipcPort is lost when this happens.
> I produced manually this by setting up a DN with IPC port set to 0 (so it picks an ephemeral port) and then restarting the DN. At this point, the NN's view of the ipcPort is stale, and clients will not be able to achieve pipeline recovery.
> This should be easy to fix and unit test, but not sure when I'll get to it, so anyone else should feel free to grab it if they get to it first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.