[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326996#comment-17326996 ] Ctest commented on HDFS-15250: -- Hello [~sodonnell] Sorry that we didn't keep the stack trace of this issue. All I remembered is that we set `dfs.client.use.datanode.hostname` to true and set the hostname of the datanode wrongly which triggers the exception. I think the system throws the correct exception here, but probably needs to handle it better. > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Assignee: Ctest >Priority: Major > Fix For: 3.2.2, 3.3.1, 3.4.0, 3.1.5 > > Attachments: HDFS-15250-001.patch, HDFS-15250-002.patch > > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326902#comment-17326902 ] Stephen O'Donnell commented on HDFS-15250: -- I am reviewing some backports and came across this one. The change here does not seem to fix anything as a couple of people have stated. Has anyone got a stack trace from an occurrence of this error so we can see where it fails exactly? > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Assignee: Ctest >Priority: Major > Fix For: 3.2.2, 3.3.1, 3.4.0, 3.1.5 > > Attachments: HDFS-15250-001.patch, HDFS-15250-002.patch > > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268463#comment-17268463 ] Benoit Sigoure commented on HDFS-15250: --- This issue is not fixed. Merely catching and logging the exception just to re-raise it doesn't solve the problem. The exception ends up preventing HDFS reads from succeeding when one of the replicas is unavailable due to UnresolvedAddressException, even though there could be other replicas available. > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Assignee: Ctest >Priority: Major > Fix For: 3.2.2, 3.3.1, 3.4.0, 3.1.5 > > Attachments: HDFS-15250-001.patch, HDFS-15250-002.patch > > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112594#comment-17112594 ] Andrey Elenskiy commented on HDFS-15250: We've run into the same issue on 3.1.3 and ended up getting UnresolvedAddressException propagated all the way to clients (readers and writers) even if only one block location was not able to be resolved. So the entire read/write fails if on datanode from pipeline causes UnresolvedAddressException. I see the patch doesn't actually handle this exception but just logs in TRACE and rethrows it, so would we expect to see the same problem? I can also try out the patch on our system as it's fairly easy to reproduce in case you think this change is enough. > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Assignee: Ctest >Priority: Major > Fix For: 3.2.2, 3.3.1, 3.4.0, 3.1.5 > > Attachments: HDFS-15250-001.patch, HDFS-15250-002.patch > > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103674#comment-17103674 ] Hudson commented on HDFS-15250: --- SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #18231 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/18231/]) HDFS-15250. Setting `dfs.client.use.datanode.hostname` to true can crash (ayushsaxena: rev aab9e0b16ecc8fa00228c00c7ab90e55195cf5f4) * (edit) hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/client/impl/BlockReaderFactory.java > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Assignee: Ctest >Priority: Major > Fix For: 3.2.2, 3.3.1, 3.4.0, 3.1.5 > > Attachments: HDFS-15250-001.patch, HDFS-15250-002.patch > > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103673#comment-17103673 ] Ayush Saxena commented on HDFS-15250: - Committed to trunk, branch-3.3,3.2 and 3.1. Thanx [~ctest.team] for the contribution. > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Assignee: Ctest >Priority: Major > Attachments: HDFS-15250-001.patch, HDFS-15250-002.patch > > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103624#comment-17103624 ] Hadoop QA commented on HDFS-15250: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m 25s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 21m 7s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 49s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 23s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 53s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 16m 38s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s{color} | {color:green} trunk passed {color} | | {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 2m 22s{color} | {color:blue} Used deprecated FindBugs config; considering switching to SpotBugs. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 20s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 48s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 45s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 17s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 46s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 15m 32s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 27s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 58s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 30s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 68m 29s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | Docker | ClientAPI=1.40 ServerAPI=1.40 base: https://builds.apache.org/job/PreCommit-HDFS-Build/29259/artifact/out/Dockerfile | | JIRA Issue | HDFS-15250 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/13002512/HDFS-15250-002.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux a05100928763 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | personality/hadoop.sh | | git revision | trunk / cb64e993c27 | | Default Java | Private Build-1.8.0_252-8u252-b09-1~18.04-b09 | | Test Results | https://builds.apache.org/job/PreCommit-HDFS-Build/29259/testReport/ | | Max. process+thread count | 295 (vs. ulimit of 5500) | | modules | C:
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103317#comment-17103317 ] Ayush Saxena commented on HDFS-15250: - Thanx [~ctest.team] for the patch. We can use the same catch block, won't make much difference having a new block, the trace message is enough to convey that connection failed that should be enough. You can change like this : {code:java} } catch (IOException | UnresolvedAddressException e) { {code} > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Assignee: Ctest >Priority: Major > Attachments: HDFS-15250-001.patch > > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101354#comment-17101354 ] Hadoop QA commented on HDFS-15250: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m 50s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} dupname {color} | {color:green} 0m 0s{color} | {color:green} No case conflicting files found. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s{color} | {color:red} The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 24m 14s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 55s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 30s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 9s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 19m 7s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s{color} | {color:green} trunk passed {color} | | {color:blue}0{color} | {color:blue} spotbugs {color} | {color:blue} 3m 21s{color} | {color:blue} Used deprecated FindBugs config; considering switching to SpotBugs. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 17s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 59s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 51s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 52s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 19s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 51s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 16m 37s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 56s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 2s{color} | {color:red} hadoop-hdfs-client in the patch passed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 29s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 77m 49s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hdfs.server.namenode.ha.TestConfiguredFailoverProxyProvider | \\ \\ || Subsystem || Report/Notes || | Docker | ClientAPI=1.40 ServerAPI=1.40 base: https://builds.apache.org/job/PreCommit-HDFS-Build/29243/artifact/out/Dockerfile | | JIRA Issue | HDFS-15250 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/13002241/HDFS-15250-001.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux dd1af6bbb7e2 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | personality/hadoop.sh | | git revision | trunk / 35010120fbb | | Default Java | Private Build-1.8.0_252-8u252-b09-1~18.04-b09 | | unit |
[jira] [Commented] (HDFS-15250) Setting `dfs.client.use.datanode.hostname` to true can crash the system because of unhandled UnresolvedAddressException
[ https://issues.apache.org/jira/browse/HDFS-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075150#comment-17075150 ] Ayush Saxena commented on HDFS-15250: - bq. I am very happy to provide a patch to do this. Go ahead!!! > Setting `dfs.client.use.datanode.hostname` to true can crash the system > because of unhandled UnresolvedAddressException > --- > > Key: HDFS-15250 > URL: https://issues.apache.org/jira/browse/HDFS-15250 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Ctest >Priority: Major > > *Problem:* > `dfs.client.use.datanode.hostname` by default is set to false, which means > the client will use the IP address of the datanode to connect to the > datanode, rather than the hostname of the datanode. > In `org.apache.hadoop.hdfs.client.impl.BlockReaderFactory.nextTcpPeer`: > > {code:java} > try { > Peer peer = remotePeerFactory.newConnectedPeer(inetSocketAddress, token, > datanode); > LOG.trace("nextTcpPeer: created newConnectedPeer {}", peer); > return new BlockReaderPeer(peer, false); > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } > {code} > > If `dfs.client.use.datanode.hostname` is false, then it will try to connect > via IP address. If the IP address is illegal and the connection fails, > IOException will be thrown from `newConnectedPeer` and be handled. > If `dfs.client.use.datanode.hostname` is true, then it will try to connect > via hostname. If the hostname cannot be resolved, UnresolvedAddressException > will be thrown from `newConnectedPeer`. However, UnresolvedAddressException > is not a subclass of IOException so `nextTcpPeer` doesn’t handle this > exception at all. This unhandled exception could crash the system. > > *Solution:* > Since the method is handling the illegal IP address, then the illegal > hostname should be also handled as well. One solution is to add the handling > logic in `nextTcpPeer`: > {code:java} > } catch (IOException e) { > LOG.trace("nextTcpPeer: failed to create newConnectedPeer connected to" > + "{}", datanode); > throw e; > } catch (UnresolvedAddressException e) { > ... // handling logic > }{code} > I am very happy to provide a patch to do this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org