[jira] [Created] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
Dhiraj Hegde created HADOOP-17052: - Summary: NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails Key: HADOOP-17052 URL: https://issues.apache.org/jira/browse/HADOOP-17052 Project: Hadoop Common Issue Type: Bug Components: hdfs-client Affects Versions: 3.1.3, 3.2.1, 2.9.2, 2.10.0 Reporter: Dhiraj Hegde Hadoop components are increasingly being deployed on VMs and containers. One aspect of this environment is that DNS is dynamic. Hostname records get modified (or deleted/recreated) as a container in Kubernetes (or even VM) is being created/recreated. In such dynamic environments, the initial DNS resolution request might return resolution failure briefly as DNS client doesn't always get the latest records. This has been observed in Kubernetes in particular. In such cases NetUtils.connect() appears to throw java.nio.channels.UnresolvedAddressException. In much of Hadoop code (like DFSInputStream and DFSOutputStream), the code is designed to retry IOException. However, since UnresolvedAddressException is not child of IOException, no retry happens and the code aborts immediately. It is much better if NetUtils.connect() throws java.net.UnknownHostException as that is derived from IOException and the code will treat this as a retry-able error. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-17047) TODO comments exist in trunk while the related issues are already fixed.
[
https://issues.apache.org/jira/browse/HADOOP-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116481#comment-17116481
]
Rungroj Maipradit commented on HADOOP-17047:
In summary, should I change the status of this issue to the patch available?
Do I need to create a sub-task for the first case?
> TODO comments exist in trunk while the related issues are already fixed.
>
>
> Key: HADOOP-17047
> URL: https://issues.apache.org/jira/browse/HADOOP-17047
> Project: Hadoop Common
> Issue Type: Improvement
>Reporter: Rungroj Maipradit
>Assignee: Rungroj Maipradit
>Priority: Trivial
> Attachments: HADOOP-17047.001.patch
>
>
> In a research project, we analyzed the source code of Hadoop looking for
> comments with on-hold SATDs (self-admitted technical debt) that could be
> fixed already. An on-hold SATD is a TODO/FIXME comment blocked by an issue.
> If this blocking issue is already resolved, the related todo can be
> implemented (or sometimes it is already implemented, but the comment is left
> in the code causing confusions). As we found a few instances of these in
> Hadoop, we decided to collect them in a ticket, so they are documented and
> can be addressed sooner or later.
> A list of code comments that mention already closed issues.
> * A code comment suggests making the setJobConf method deprecated along with
> a mapred package HADOOP-1230. HADOOP-1230 has been closed a long time ago,
> but the method is still not annotated as deprecated.
> {code:java}
> /**
>* This code is to support backward compatibility and break the compile
>* time dependency of core on mapred.
>* This should be made deprecated along with the mapred package
> HADOOP-1230.
>* Should be removed when mapred package is removed.
>*/ {code}
> Comment location:
> [https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/ReflectionUtils.java#L88]
> * A comment mentions that the return type of the getDefaultFileSystem method
> should be changed to AFS when HADOOP-6223 is completed.
> Indeed, this change was done in the related commit of HADOOP-6223:
> ([https://github.com/apache/hadoop/commit/3f371a0a644181b204111ee4e12c995fc7b5e5f5#diff-cd86a2b9ce3efd2232c2ace0e9084508L395)]
> Thus, the comment could be removed.
> {code:java}
> @InterfaceStability.Unstable /* return type will change to AFS once
> HADOOP-6223 is completed */
> {code}
> Comment location:
> [https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileContext.java#L512]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17053) ABFS: FS initialize fails for incompatible account-agnostic Token Provider setting
[ https://issues.apache.org/jira/browse/HADOOP-17053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sneha Vijayarajan updated HADOOP-17053: --- Status: Patch Available (was: Open) > ABFS: FS initialize fails for incompatible account-agnostic Token Provider > setting > --- > > Key: HADOOP-17053 > URL: https://issues.apache.org/jira/browse/HADOOP-17053 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > When AuthType and Auth token provider configs are set for both generic and > account specific config, as below: > // account agnostic > fs.azure.account.auth.type=CUSTOM > fs.azure.account.oauth.provider.type=ClassExtendingCustomTokenProviderAdapter > // account specific > fs.azure.account.auth.type.account_name=OAuth > fs.azure.account.oauth.provider.type.account_name=ClassExtendingAccessTokenProvider > For account_name, OAuth with provider as ClassExtendingAccessTokenProvider > is expected to be in effect. > When the token provider class is being read from the config, account agnostic > config setting is read first in the assumption that it can serve as default > if account-specific config setting is absent. But this logic leads to failure > when AuthType set for account specific and otherwise are different as the > Interface implementing the token provider is different for various Auth > Types. This leads to a Runtime exception when trying to create the oAuth > access token provider. > This Jira is to track the fix for it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17054) ABFS: Fix idempotency test failures when SharedKey is set as AuthType
[ https://issues.apache.org/jira/browse/HADOOP-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sneha Vijayarajan updated HADOOP-17054: --- Resolution: Fixed Status: Resolved (was: Patch Available) > ABFS: Fix idempotency test failures when SharedKey is set as AuthType > - > > Key: HADOOP-17054 > URL: https://issues.apache.org/jira/browse/HADOOP-17054 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > Idempotency related tests added as part of > https://issues.apache.org/jira/browse/HADOOP-17015 > create a test AbfsClient instance. This mock instance wrongly accepts valid > sharedKey and oauth token provider instance. This leads to test failures with > exceptions: > [ERROR] > testRenameRetryFailureAsHTTP404(org.apache.hadoop.fs.azurebfs.ITestAzureBlobFileSystemRename) > Time elapsed: 9.133 s <<< ERROR! > Invalid auth type: SharedKey is being used, expecting OAuth > at > org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider(AbfsConfiguration.java:643) > This Jira is to fix these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-17054) ABFS: Fix idempotency test failures when SharedKey is set as AuthType
[ https://issues.apache.org/jira/browse/HADOOP-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117159#comment-17117159 ] Hudson commented on HADOOP-17054: - SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #18296 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/18296/]) HADOOP-17054. ABFS: Fix test AbfsClient authentication instance (github: rev 37b1b4799db680d4a8bd4cb389e00d044f1e4a37) * (edit) hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azurebfs/services/TestAbfsClient.java > ABFS: Fix idempotency test failures when SharedKey is set as AuthType > - > > Key: HADOOP-17054 > URL: https://issues.apache.org/jira/browse/HADOOP-17054 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > Idempotency related tests added as part of > https://issues.apache.org/jira/browse/HADOOP-17015 > create a test AbfsClient instance. This mock instance wrongly accepts valid > sharedKey and oauth token provider instance. This leads to test failures with > exceptions: > [ERROR] > testRenameRetryFailureAsHTTP404(org.apache.hadoop.fs.azurebfs.ITestAzureBlobFileSystemRename) > Time elapsed: 9.133 s <<< ERROR! > Invalid auth type: SharedKey is being used, expecting OAuth > at > org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider(AbfsConfiguration.java:643) > This Jira is to fix these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
[ https://issues.apache.org/jira/browse/HADOOP-17052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116992#comment-17116992 ] Dhiraj Hegde commented on HADOOP-17052: --- [~hemanthboyina] Here is a stack trace of read failing due to the exception thrown: Caused by: java.nio.channels.UnresolvedAddressException at sun.nio.ch.Net.checkAddress(Net.java:101) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:622) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:192) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531) at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3363) at org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:817) at org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:710) at org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356) at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:666) at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:875) at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:927) ... FATAL [MemStoreFlusher.0] regionserver.HRegionServer - ABORTING region server > NetUtils.connect() throws an exception the prevents any retries when hostname > resolution fails > -- > > Key: HADOOP-17052 > URL: https://issues.apache.org/jira/browse/HADOOP-17052 > Project: Hadoop Common > Issue Type: Bug > Components: hdfs-client >Affects Versions: 2.10.0, 2.9.2, 3.2.1, 3.1.3 >Reporter: Dhiraj Hegde >Assignee: Dhiraj Hegde >Priority: Major > > Hadoop components are increasingly being deployed on VMs and containers. One > aspect of this environment is that DNS is dynamic. Hostname records get > modified (or deleted/recreated) as a container in Kubernetes (or even VM) is > being created/recreated. In such dynamic environments, the initial DNS > resolution request might return resolution failure briefly as DNS client > doesn't always get the latest records. This has been observed in Kubernetes > in particular. In such cases NetUtils.connect() appears to throw > java.nio.channels.UnresolvedAddressException. In much of Hadoop code (like > DFSInputStream and DFSOutputStream), the code is designed to retry > IOException. However, since UnresolvedAddressException is not child of > IOException, no retry happens and the code aborts immediately. It is much > better if NetUtils.connect() throws java.net.UnknownHostException as that is > derived from IOException and the code will treat this as a retry-able error. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
[
https://issues.apache.org/jira/browse/HADOOP-17052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116998#comment-17116998
]
Dhiraj Hegde commented on HADOOP-17052:
---
Here is one for the write pipeline:
{code:java}
java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Net.java:101)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:622)
at
org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:192)
at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531)
at
org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3483)
at
org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:796)
at
org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:694)
at
org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:355)
at
org.apache.hadoop.hdfs.DFSInputStream.actualGetFromOneDataNode(DFSInputStream.java:1162)
at
org.apache.hadoop.hdfs.DFSInputStream.fetchBlockByteRange(DFSInputStream.java:1087)
at org.apache.hadoop.hdfs.DFSInputStream.pread(DFSInputStream.java:1444)
at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:1407)
at
org.apache.hadoop.fs.FSDataInputStream.read(FSDataInputStream.java:89)
at
org.apache.hadoop.hbase.io.hfile.HFileBlock.positionalReadWithExtra(HFileBlock.java:834)
at
org.apache.hadoop.hbase.io.hfile.HFileBlock$AbstractFSReader.readAtOffset(HFileBlock.java:1530)
at
org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderImpl.readBlockDataInternal(HFileBlock.java:1797)
at
org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderImpl.readBlockData(HFileBlock.java:1624)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:455)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.readNextDataBlock(HFileReaderV2.java:733)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.isNextBlock(HFileReaderV2.java:858)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.positionForNextBlock(HFileReaderV2.java:853)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2._next(HFileReaderV2.java:870)
at
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.next(HFileReaderV2.java:890)
at
org.apache.hadoop.hbase.regionserver.StoreFileScanner.next(StoreFileScanner.java:169)
at
org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:113)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:667)
at
org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:152)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:6175)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:6335)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6113)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.next(HRegion.java:6090)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.next(HRegion.java:6076)
at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:7258)
at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:7216)
at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:7209)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2273)
at
org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:35068)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2417)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124)
at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:186)
at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:166)
{code}
> NetUtils.connect() throws an exception the prevents any retries when hostname
> resolution fails
> --
>
> Key: HADOOP-17052
> URL: https://issues.apache.org/jira/browse/HADOOP-17052
> Project: Hadoop Common
> Issue Type: Bug
> Components: hdfs-client
>Affects Versions: 2.10.0, 2.9.2, 3.2.1, 3.1.3
>Reporter: Dhiraj Hegde
>Assignee: Dhiraj Hegde
>Priority: Major
>
> Hadoop components are increasingly being deployed on VMs and containers. One
> aspect of this environment is that DNS is dynamic. Hostname records get
> modified (or deleted/recreated) as a container in Kubernetes (or even VM) is
> being created/recreated. In
[jira] [Commented] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
[ https://issues.apache.org/jira/browse/HADOOP-17052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117006#comment-17117006 ] Dhiraj Hegde commented on HADOOP-17052: --- The code change could be made a level above in places like newConnectedPeer(). My original thought was that java.net.UnknownHostException might be a better one for NetUtils.connect() to throw and one being thrown right now wasn't really an intentional decision in connect(). Let me know what you think [~hemanthboyina]. > NetUtils.connect() throws an exception the prevents any retries when hostname > resolution fails > -- > > Key: HADOOP-17052 > URL: https://issues.apache.org/jira/browse/HADOOP-17052 > Project: Hadoop Common > Issue Type: Bug > Components: hdfs-client >Affects Versions: 2.10.0, 2.9.2, 3.2.1, 3.1.3 >Reporter: Dhiraj Hegde >Assignee: Dhiraj Hegde >Priority: Major > > Hadoop components are increasingly being deployed on VMs and containers. One > aspect of this environment is that DNS is dynamic. Hostname records get > modified (or deleted/recreated) as a container in Kubernetes (or even VM) is > being created/recreated. In such dynamic environments, the initial DNS > resolution request might return resolution failure briefly as DNS client > doesn't always get the latest records. This has been observed in Kubernetes > in particular. In such cases NetUtils.connect() appears to throw > java.nio.channels.UnresolvedAddressException. In much of Hadoop code (like > DFSInputStream and DFSOutputStream), the code is designed to retry > IOException. However, since UnresolvedAddressException is not child of > IOException, no retry happens and the code aborts immediately. It is much > better if NetUtils.connect() throws java.net.UnknownHostException as that is > derived from IOException and the code will treat this as a retry-able error. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Created] (HADOOP-17053) ABFS: FS initialize fails for incompatible account-agnostic Token Provider setting
Sneha Vijayarajan created HADOOP-17053: -- Summary: ABFS: FS initialize fails for incompatible account-agnostic Token Provider setting Key: HADOOP-17053 URL: https://issues.apache.org/jira/browse/HADOOP-17053 Project: Hadoop Common Issue Type: Sub-task Components: fs/azure Affects Versions: 3.2.1 Reporter: Sneha Vijayarajan Assignee: Sneha Vijayarajan Fix For: 3.4.0 When AuthType and Auth token provider configs are set for both generic and account specific config, as below: // account agnostic fs.azure.account.auth.type=CUSTOM fs.azure.account.oauth.provider.type=ClassExtendingCustomTokenProviderAdapter // account specific fs.azure.account.auth.type.account_name=OAuth fs.azure.account.oauth.provider.type.account_name=ClassExtendingAccessTokenProvider For account_name, OAuth with provider as ClassExtendingAccessTokenProvider is expected to be in effect. When the token provider class is being read from the config, account agnostic config setting is read first in the assumption that it can serve as default if account-specific config setting is absent. But this logic leads to failure when AuthType set for account specific and otherwise are different as the Interface implementing the token provider is different for various Auth Types. This leads to a Runtime exception when trying to create the oAuth access token provider. This Jira is to track the fix for it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Created] (HADOOP-17054) ABFS: Fix idempotency test failures when SharedKey is set as AuthType
Sneha Vijayarajan created HADOOP-17054: -- Summary: ABFS: Fix idempotency test failures when SharedKey is set as AuthType Key: HADOOP-17054 URL: https://issues.apache.org/jira/browse/HADOOP-17054 Project: Hadoop Common Issue Type: Sub-task Components: fs/azure Affects Versions: 3.2.1 Reporter: Sneha Vijayarajan Assignee: Sneha Vijayarajan Fix For: 3.4.0 Idempotency related tests added as part of https://issues.apache.org/jira/browse/HADOOP-17015 create a test AbfsClient instance. This mock instance wrongly accepts valid sharedKey and oauth token provider instance. This leads to test failures with exceptions: [ERROR] testRenameRetryFailureAsHTTP404(org.apache.hadoop.fs.azurebfs.ITestAzureBlobFileSystemRename) Time elapsed: 9.133 s <<< ERROR! Invalid auth type: SharedKey is being used, expecting OAuth at org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider(AbfsConfiguration.java:643) This Jira is to fix these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
[ https://issues.apache.org/jira/browse/HADOOP-17052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mingliang Liu reassigned HADOOP-17052: -- Assignee: Dhiraj Hegde > NetUtils.connect() throws an exception the prevents any retries when hostname > resolution fails > -- > > Key: HADOOP-17052 > URL: https://issues.apache.org/jira/browse/HADOOP-17052 > Project: Hadoop Common > Issue Type: Bug > Components: hdfs-client >Affects Versions: 2.10.0, 2.9.2, 3.2.1, 3.1.3 >Reporter: Dhiraj Hegde >Assignee: Dhiraj Hegde >Priority: Major > > Hadoop components are increasingly being deployed on VMs and containers. One > aspect of this environment is that DNS is dynamic. Hostname records get > modified (or deleted/recreated) as a container in Kubernetes (or even VM) is > being created/recreated. In such dynamic environments, the initial DNS > resolution request might return resolution failure briefly as DNS client > doesn't always get the latest records. This has been observed in Kubernetes > in particular. In such cases NetUtils.connect() appears to throw > java.nio.channels.UnresolvedAddressException. In much of Hadoop code (like > DFSInputStream and DFSOutputStream), the code is designed to retry > IOException. However, since UnresolvedAddressException is not child of > IOException, no retry happens and the code aborts immediately. It is much > better if NetUtils.connect() throws java.net.UnknownHostException as that is > derived from IOException and the code will treat this as a retry-able error. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-17050) Add support for multiple delegation tokens in S3AFilesystem
[
https://issues.apache.org/jira/browse/HADOOP-17050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota reassigned HADOOP-17050:
---
Assignee: Steve Loughran (was: Gabor Bota)
> Add support for multiple delegation tokens in S3AFilesystem
> ---
>
> Key: HADOOP-17050
> URL: https://issues.apache.org/jira/browse/HADOOP-17050
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Reporter: Gabor Bota
>Assignee: Steve Loughran
>Priority: Major
>
> In
> {{org.apache.hadoop.fs.s3a.auth.delegation.AbstractDelegationTokenBinding}}
> the {{createDelegationToken}} should return a list of tokens.
> With this functionality, the {{AbstractDelegationTokenBinding}} can get two
> different tokens at the same time.
> {{AbstractDelegationTokenBinding.TokenSecretManager}} should be extended to
> retrieve secrets and lookup delegation tokens (use the public API for
> secretmanager in hadoop)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
[
https://issues.apache.org/jira/browse/HADOOP-17052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116957#comment-17116957
]
hemanthboyina commented on HADOOP-17052:
Thanks for reporting [~dhegde]
do you have any stack trace of the exception ?
An Example : In DataStreamer#createSocketForPipeline we call NetUtils.connect()
{code:java}
final InetSocketAddress isa = NetUtils.createSocketAddr(dnAddr);
final Socket sock = client.socketFactory.createSocket();
final int timeout = client.getDatanodeReadTimeout(length);
NetUtils.connect(sock, isa, client.getRandomLocalInterfaceAddr(),
conf.getSocketTimeout()); {code}
we resolve the DN address and calls the NetUtils.connect() , is there any
chance of getting reported scenario in this part of code ?
> NetUtils.connect() throws an exception the prevents any retries when hostname
> resolution fails
> --
>
> Key: HADOOP-17052
> URL: https://issues.apache.org/jira/browse/HADOOP-17052
> Project: Hadoop Common
> Issue Type: Bug
> Components: hdfs-client
>Affects Versions: 2.10.0, 2.9.2, 3.2.1, 3.1.3
>Reporter: Dhiraj Hegde
>Assignee: Dhiraj Hegde
>Priority: Major
>
> Hadoop components are increasingly being deployed on VMs and containers. One
> aspect of this environment is that DNS is dynamic. Hostname records get
> modified (or deleted/recreated) as a container in Kubernetes (or even VM) is
> being created/recreated. In such dynamic environments, the initial DNS
> resolution request might return resolution failure briefly as DNS client
> doesn't always get the latest records. This has been observed in Kubernetes
> in particular. In such cases NetUtils.connect() appears to throw
> java.nio.channels.UnresolvedAddressException. In much of Hadoop code (like
> DFSInputStream and DFSOutputStream), the code is designed to retry
> IOException. However, since UnresolvedAddressException is not child of
> IOException, no retry happens and the code aborts immediately. It is much
> better if NetUtils.connect() throws java.net.UnknownHostException as that is
> derived from IOException and the code will treat this as a retry-able error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17054) ABFS: Fix idempotency test failures when SharedKey is set as AuthType
[ https://issues.apache.org/jira/browse/HADOOP-17054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sneha Vijayarajan updated HADOOP-17054: --- Status: Patch Available (was: Open) > ABFS: Fix idempotency test failures when SharedKey is set as AuthType > - > > Key: HADOOP-17054 > URL: https://issues.apache.org/jira/browse/HADOOP-17054 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/azure >Affects Versions: 3.2.1 >Reporter: Sneha Vijayarajan >Assignee: Sneha Vijayarajan >Priority: Major > Fix For: 3.4.0 > > > Idempotency related tests added as part of > https://issues.apache.org/jira/browse/HADOOP-17015 > create a test AbfsClient instance. This mock instance wrongly accepts valid > sharedKey and oauth token provider instance. This leads to test failures with > exceptions: > [ERROR] > testRenameRetryFailureAsHTTP404(org.apache.hadoop.fs.azurebfs.ITestAzureBlobFileSystemRename) > Time elapsed: 9.133 s <<< ERROR! > Invalid auth type: SharedKey is being used, expecting OAuth > at > org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider(AbfsConfiguration.java:643) > This Jira is to fix these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] snvijaya opened a new pull request #2033: HADOOP-17054. ABFS: Fix test AbfsClient authentication instance
snvijaya opened a new pull request #2033: URL: https://github.com/apache/hadoop/pull/2033 Idempotency related tests added as part of https://issues.apache.org/jira/browse/HADOOP-17015 create a test AbfsClient instance. This mock instance wrongly accepts valid sharedKey and oauth token provider instance instead of only one. This leads to test failures with exception message : "Invalid auth type: SharedKey is being used, expecting OAuth" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] hadoop-yetus commented on pull request #2033: HADOOP-17054. ABFS: Fix test AbfsClient authentication instance
hadoop-yetus commented on pull request #2033: URL: https://github.com/apache/hadoop/pull/2033#issuecomment-634241367 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] snvijaya commented on pull request #2034: HADOOP-17053. ABFS: Fix Account-specific OAuth config setting parsing
snvijaya commented on pull request #2034: URL: https://github.com/apache/hadoop/pull/2034#issuecomment-634304396 Accounts are in East US2 region. Non-HNS Account: [INFO] Tests run: 65, Failures: 0, Errors: 0, Skipped: 0 [WARNING] Tests run: 436, Failures: 0, Errors: 0, Skipped: 248 [WARNING] Tests run: 206, Failures: 0, Errors: 0, Skipped: 140 HNS Account: [INFO] Tests run: 65, Failures: 0, Errors: 0, Skipped: 0 [WARNING] Tests run: 436, Failures: 0, Errors: 0, Skipped: 74 [WARNING] Tests run: 206, Failures: 0, Errors: 0, Skipped: 140 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] DadanielZ merged pull request #2033: HADOOP-17054. ABFS: Fix test AbfsClient authentication instance
DadanielZ merged pull request #2033: URL: https://github.com/apache/hadoop/pull/2033 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] goiri commented on a change in pull request #2031: HDFS-15371 Nonstandard characters exist in NameNode.java
goiri commented on a change in pull request #2031: URL: https://github.com/apache/hadoop/pull/2031#discussion_r430031378 ## File path: hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java ## @@ -300,7 +300,7 @@ DFS_NAMENODE_KERBEROS_PRINCIPAL_KEY, DFS_NAMENODE_KERBEROS_INTERNAL_SPNEGO_PRINCIPAL_KEY, DFS_HA_FENCE_METHODS_KEY, -DFS_HA_ZKFC_PORT_KEY, Review comment: Does anything break because of this comma? I personally don't see a point on removing this. If we add a new key, it will reduce churn. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] hadoop-yetus commented on pull request #2034: HADOOP-17053. ABFS: Fix Account-specific OAuth config setting parsing
hadoop-yetus commented on pull request #2034: URL: https://github.com/apache/hadoop/pull/2034#issuecomment-634333525 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | +0 :ok: | reexec | 0m 39s | Docker mode activated. | ||| _ Prechecks _ | | +1 :green_heart: | dupname | 0m 0s | No case conflicting files found. | | +1 :green_heart: | @author | 0m 0s | The patch does not contain any @author tags. | | +1 :green_heart: | test4tests | 0m 0s | The patch appears to include 1 new or modified test files. | ||| _ trunk Compile Tests _ | | +1 :green_heart: | mvninstall | 19m 40s | trunk passed | | +1 :green_heart: | compile | 0m 33s | trunk passed | | +1 :green_heart: | checkstyle | 0m 24s | trunk passed | | +1 :green_heart: | mvnsite | 0m 35s | trunk passed | | +1 :green_heart: | shadedclient | 14m 46s | branch has no errors when building and testing our client artifacts. | | +1 :green_heart: | javadoc | 0m 28s | trunk passed | | +0 :ok: | spotbugs | 0m 51s | Used deprecated FindBugs config; considering switching to SpotBugs. | | +1 :green_heart: | findbugs | 0m 49s | trunk passed | ||| _ Patch Compile Tests _ | | +1 :green_heart: | mvninstall | 0m 29s | the patch passed | | +1 :green_heart: | compile | 0m 23s | the patch passed | | +1 :green_heart: | javac | 0m 23s | the patch passed | | +1 :green_heart: | checkstyle | 0m 16s | the patch passed | | +1 :green_heart: | mvnsite | 0m 27s | the patch passed | | +1 :green_heart: | whitespace | 0m 0s | The patch has no whitespace issues. | | +1 :green_heart: | shadedclient | 13m 37s | patch has no errors when building and testing our client artifacts. | | +1 :green_heart: | javadoc | 0m 24s | the patch passed | | -1 :x: | findbugs | 0m 57s | hadoop-tools/hadoop-azure generated 2 new + 0 unchanged - 0 fixed = 2 total (was 0) | ||| _ Other Tests _ | | +1 :green_heart: | unit | 1m 25s | hadoop-azure in the patch passed. | | +1 :green_heart: | asflicense | 0m 31s | The patch does not generate ASF License warnings. | | | | 58m 15s | | | Reason | Tests | |---:|:--| | FindBugs | module:hadoop-tools/hadoop-azure | | | Possible null pointer dereference of tokenProviderClass in org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProviderClass(AuthType, String, Class, Class) Dereferenced at AbfsConfiguration.java:tokenProviderClass in org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProviderClass(AuthType, String, Class, Class) Dereferenced at AbfsConfiguration.java:[line 353] | | | Redundant nullcheck of customTokenProviderClass, which is known to be non-null in org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider() Redundant null check at AbfsConfiguration.java:is known to be non-null in org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getTokenProvider() Redundant null check at AbfsConfiguration.java:[line 678] | | Subsystem | Report/Notes | |--:|:-| | Docker | ClientAPI=1.40 ServerAPI=1.40 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-2034/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hadoop/pull/2034 | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 87fad64479ad 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | personality/hadoop.sh | | git revision | trunk / 37b1b4799db | | Default Java | Private Build-1.8.0_252-8u252-b09-1~18.04-b09 | | findbugs | https://builds.apache.org/job/hadoop-multibranch/job/PR-2034/1/artifact/out/new-findbugs-hadoop-tools_hadoop-azure.html | | Test Results | https://builds.apache.org/job/hadoop-multibranch/job/PR-2034/1/testReport/ | | Max. process+thread count | 475 (vs. ulimit of 5500) | | modules | C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure | | Console output | https://builds.apache.org/job/hadoop-multibranch/job/PR-2034/1/console | | versions | git=2.17.1 maven=3.6.0 findbugs=3.1.0-RC1 | | Powered by | Apache Yetus 0.12.0 https://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail:
[GitHub] [hadoop] snvijaya opened a new pull request #2034: HADOOP-17053. ABFS: Fix Account-specific OAuth config setting parsing
snvijaya opened a new pull request #2034: URL: https://github.com/apache/hadoop/pull/2034 When AuthType and Auth token provider configs are set for both generic (account-agnostic) and account-specific config, as below: // account agnostic fs.azure.account.auth.type=CUSTOM fs.azure.account.oauth.provider.type=ClassExtendingCustomTokenProviderAdapter // account specific fs.azure.account.auth.type.account_name=OAuth fs.azure.account.oauth.provider.type.account_name=ClassExtendingAccessTokenProvider Effective token provider for 'account_name' is expected to be ClassExtendingAccessTokenProvider. But currently, when the token provider class is being read from the config, account-agnostic config setting is read first in the assumption that it can serve as default if account-specific config setting is absent. This logic leads to failure such as in above case where AuthType for account-specific and AuthType for account-agnostic are different. This is because the Interface implementing the token provider is different for various Auth Types (For Custom AuthType it is CustomTokenProviderAdapter and for OAuth it is AccessTokenProvider). This leads to a Runtime exception when trying to create the oAuth access token provider. In this PR, getTokenProvider() is fixed to check for account-specific token provider configuration first. In its absence, account-agnostic token provider configuration is read only if account-specific and account-agnostic AuthType setting is same (otherwise expected token provider interface is different). The same logic applies while determining SAS Token provider too, hence that has been updated as well. Testing is done with combinations of Custom and OAuth settings in account-specific and account-agnostic configs and determining which is in effect. Tested getSASTokenProvider which uses the same logic to find the effective token provider with SAS set for both account-specific and account-agnostic configs. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] umamaheswararao commented on a change in pull request #2019: HADOOP-17029. Return correct permission and owner for listing on internal directories in ViewFs
umamaheswararao commented on a change in pull request #2019:
URL: https://github.com/apache/hadoop/pull/2019#discussion_r430611396
##
File path:
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFs.java
##
@@ -915,11 +915,24 @@ public FileStatus getFileLinkStatus(final Path f)
if (inode.isLink()) {
INodeLink inodelink =
(INodeLink) inode;
-result = new FileStatus(0, false, 0, 0, creationTime, creationTime,
+Path linkedPath = new Path(inodelink.targetDirLinkList[0].toString());
+ChRootedFs linkedFs = (ChRootedFs) inodelink.getTargetFileSystem();
+try {
+ FileStatus status = linkedFs.getMyFs().getFileStatus(linkedPath);
+ result = new FileStatus(status.getLen(), false,
+status.getReplication(), status.getBlockSize(),
+status.getModificationTime(), status.getAccessTime(),
+status.getPermission(), status.getOwner(), status.getGroup(),
+inodelink.getTargetLink(),
+new Path(inode.fullPath).makeQualified(
+myUri, null));
+} catch (FileNotFoundException ex) {
Review comment:
> similar comment regarding FileNotFoundException. I think in general,
it's better to match behavior of non-federated client. If a path does not
exist, just throw back FileNotFoundException.
I just verified symlinks. When target deleted, ls on symlink does not throw
FNFE. Instead it is converted to file link. I tested dir->dir link.
It seems this behavior is correct when compared with other fs. I tested on
my MAC.
Should this be fixed in federated clusters is necessary ? Could you please
validate this?
If we attempt to open that non existent link file, then we can throw out
exception. But ls seems to simply pass.
```
Work % mkdir linkTarget
Work % ln -s linkTarget linkSrc
Work % ls -l
lrwxr-xr-x 1 umagangumalla 10 May 26 11:08 linkSrc -> linkTarget
Work % rm -rf linkTarget
Work % ls -l
lrwxr-xr-x 1 umagangumalla 10 May 26 11:08 linkSrc -> linkTarget
Work % cd linkSrc
cd: no such file or directory: linkSrc
```
##
File path:
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java
##
@@ -1211,13 +1211,29 @@ public FileStatus getFileStatus(Path f) throws
IOException {
INode inode = iEntry.getValue();
if (inode.isLink()) {
INodeLink link = (INodeLink) inode;
-
- result[i++] = new FileStatus(0, false, 0, 0,
-creationTime, creationTime, PERMISSION_555,
-ugi.getShortUserName(), ugi.getPrimaryGroupName(),
-link.getTargetLink(),
-new Path(inode.fullPath).makeQualified(
-myUri, null));
+ // For MERGE or NFLY links, the first target link is considered
+ // for fetching the FileStatus with an assumption that the permission
+ // and the owner will be the same for all the target directories.
+ Path linkedPath = new Path(link.targetDirLinkList[0].toString());
Review comment:
instead of link.targetDirLinkList[0],
link.getTargetFileSystem().getUri() should work?
This might work for nfly also I think. Because nfly has its own
GetFileStatus impl, probably we should use that impl only instead of getting
one targetDirLinkList[0]
##
File path:
hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/viewfs/TestViewfsFileStatus.java
##
@@ -56,38 +69,71 @@ public void testFileStatusSerialziation()
File infile = new File(TEST_DIR, testfilename);
final byte[] content = "dingos".getBytes();
-FileOutputStream fos = null;
-try {
- fos = new FileOutputStream(infile);
+try (FileOutputStream fos = new FileOutputStream(infile)) {
fos.write(content);
-} finally {
- if (fos != null) {
-fos.close();
- }
}
assertEquals((long)content.length, infile.length());
Configuration conf = new Configuration();
ConfigUtil.addLink(conf, "/foo/bar/baz", TEST_DIR.toURI());
-FileSystem vfs = FileSystem.get(FsConstants.VIEWFS_URI, conf);
-assertEquals(ViewFileSystem.class, vfs.getClass());
-Path path = new Path("/foo/bar/baz", testfilename);
-FileStatus stat = vfs.getFileStatus(path);
-assertEquals(content.length, stat.getLen());
-ContractTestUtils.assertNotErasureCoded(vfs, path);
-assertTrue(path + " should have erasure coding unset in " +
-"FileStatus#toString(): " + stat,
-stat.toString().contains("isErasureCoded=false"));
-
-// check serialization/deserialization
-DataOutputBuffer dob = new DataOutputBuffer();
-stat.write(dob);
-DataInputBuffer dib = new DataInputBuffer();
-dib.reset(dob.getData(), 0, dob.getLength());
-FileStatus deSer = new FileStatus();
-
[jira] [Comment Edited] (HADOOP-17029) ViewFS does not return correct user/group and ACL
[ https://issues.apache.org/jira/browse/HADOOP-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106741#comment-17106741 ] Uma Maheswara Rao G edited comment on HADOOP-17029 at 5/27/20, 2:11 AM: [~umamaheswararao] Can you please take a look at the PR for this when you get a chance. Thanks. The PR link [https://github.com/apache/hadoop/pull/2019] was (Author: abhishekd): [~g.umamah...@gmail.com] Can you please take a look at the PR for this when you get a chance. Thanks. The PR link [https://github.com/apache/hadoop/pull/2019] > ViewFS does not return correct user/group and ACL > - > > Key: HADOOP-17029 > URL: https://issues.apache.org/jira/browse/HADOOP-17029 > Project: Hadoop Common > Issue Type: Bug > Components: fs, viewfs >Reporter: Abhishek Das >Assignee: Abhishek Das >Priority: Major > > When doing ls on a mount point parent, the returned user/group ACL is > incorrect. It always showing the user and group being current user, with some > arbitrary ACL. Which could misleading any application depending on this API. > cc [~cliang] [~virajith] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
[ https://issues.apache.org/jira/browse/HADOOP-17052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Hegde updated HADOOP-17052: -- Attachment: stack_trace2 > NetUtils.connect() throws an exception the prevents any retries when hostname > resolution fails > -- > > Key: HADOOP-17052 > URL: https://issues.apache.org/jira/browse/HADOOP-17052 > Project: Hadoop Common > Issue Type: Bug > Components: hdfs-client >Affects Versions: 2.10.0, 2.9.2, 3.2.1, 3.1.3 >Reporter: Dhiraj Hegde >Assignee: Dhiraj Hegde >Priority: Major > Attachments: stack_trace2 > > > Hadoop components are increasingly being deployed on VMs and containers. One > aspect of this environment is that DNS is dynamic. Hostname records get > modified (or deleted/recreated) as a container in Kubernetes (or even VM) is > being created/recreated. In such dynamic environments, the initial DNS > resolution request might return resolution failure briefly as DNS client > doesn't always get the latest records. This has been observed in Kubernetes > in particular. In such cases NetUtils.connect() appears to throw > java.nio.channels.UnresolvedAddressException. In much of Hadoop code (like > DFSInputStream and DFSOutputStream), the code is designed to retry > IOException. However, since UnresolvedAddressException is not child of > IOException, no retry happens and the code aborts immediately. It is much > better if NetUtils.connect() throws java.net.UnknownHostException as that is > derived from IOException and the code will treat this as a retry-able error. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-17052) NetUtils.connect() throws an exception the prevents any retries when hostname resolution fails
[ https://issues.apache.org/jira/browse/HADOOP-17052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117246#comment-17117246 ] Dhiraj Hegde commented on HADOOP-17052: --- Some additional stack trace which came from a different callstack: [^stack_trace2] > NetUtils.connect() throws an exception the prevents any retries when hostname > resolution fails > -- > > Key: HADOOP-17052 > URL: https://issues.apache.org/jira/browse/HADOOP-17052 > Project: Hadoop Common > Issue Type: Bug > Components: hdfs-client >Affects Versions: 2.10.0, 2.9.2, 3.2.1, 3.1.3 >Reporter: Dhiraj Hegde >Assignee: Dhiraj Hegde >Priority: Major > Attachments: stack_trace2 > > > Hadoop components are increasingly being deployed on VMs and containers. One > aspect of this environment is that DNS is dynamic. Hostname records get > modified (or deleted/recreated) as a container in Kubernetes (or even VM) is > being created/recreated. In such dynamic environments, the initial DNS > resolution request might return resolution failure briefly as DNS client > doesn't always get the latest records. This has been observed in Kubernetes > in particular. In such cases NetUtils.connect() appears to throw > java.nio.channels.UnresolvedAddressException. In much of Hadoop code (like > DFSInputStream and DFSOutputStream), the code is designed to retry > IOException. However, since UnresolvedAddressException is not child of > IOException, no retry happens and the code aborts immediately. It is much > better if NetUtils.connect() throws java.net.UnknownHostException as that is > derived from IOException and the code will treat this as a retry-able error. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] snvijaya commented on pull request #2033: HADOOP-17054. ABFS: Fix test AbfsClient authentication instance
snvijaya commented on pull request #2033: URL: https://github.com/apache/hadoop/pull/2033#issuecomment-634196998 Test accounts are in East US2. AuthType: SharedKey [INFO] Tests run: 63, Failures: 0, Errors: 0, Skipped: 0 [WARNING] Tests run: 436, Failures: 0, Errors: 0, Skipped: 41 [WARNING] Tests run: 206, Failures: 0, Errors: 0, Skipped: 24 AuthType: OAuth - HNS Enabled [INFO] Tests run: 63, Failures: 0, Errors: 0, Skipped: 0 [WARNING] Tests run: 436, Failures: 0, Errors: 0, Skipped: 74 [WARNING] Tests run: 206, Failures: 0, Errors: 0, Skipped: 140 AuthType: OAuth - Non-HNS [INFO] Tests run: 63, Failures: 0, Errors: 0, Skipped: 0 [WARNING] Tests run: 436, Failures: 0, Errors: 0, Skipped: 248 [WARNING] Tests run: 206, Failures: 0, Errors: 0, Skipped: 140 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[GitHub] [hadoop] zhaoyim commented on a change in pull request #2031: HDFS-15371 Nonstandard characters exist in NameNode.java
zhaoyim commented on a change in pull request #2031: URL: https://github.com/apache/hadoop/pull/2031#discussion_r430118862 ## File path: hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java ## @@ -300,7 +300,7 @@ DFS_NAMENODE_KERBEROS_PRINCIPAL_KEY, DFS_NAMENODE_KERBEROS_INTERNAL_SPNEGO_PRINCIPAL_KEY, DFS_HA_FENCE_METHODS_KEY, -DFS_HA_ZKFC_PORT_KEY, Review comment: @goiri It is not break anything, I think the issue opener means the redundant comma is not formal java grammar. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
