[
https://issues.apache.org/jira/browse/HADOOP-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799826#comment-15799826
]
Mingliang Liu commented on HADOOP-13934:
----------------------------------------
Thanks [[email protected]].
[HADOOP-9258] brought the contract test {{testRenameToDirWithSamePrefix}}. It's
not very new but correct, it's not on branch-2.
Basically there are two problems that fail the integration test:
# Shared test directory among test methods may be polluted when running
{{testRenameToDirWithSamePrefix}}. I got exception when running the whole test
class saying {{S3AFileSystem.java:rename(659)) - rename
`s3a://mliu-s3guard/user/mliu/test/parentdir' to
`s3a://mliu-s3guard/user/mliu/test/parentdirdest': Destination is a non-empty
directory}}.
#- As code {{path("test/parentdir");}} in
{{testRenameToDirWithSamePrefixAllowed()}}, the path is not absolute. This will
simply use the working directory as its parent, e.g. {{/user/mliu/test/}}.
However, the tearDown is gonna delete subtree {{/test}} instead. So the test
directory is not cleaned up between tests.
#- Another unrelated problem is that {{ITestS3AFileSystemContract#path()}}
method that constructs a new base path per test suite seems flaky. The result
is that, the basePath {{/s3afilesystemcontract}} is not used in the test.
{code}
protected Path path(String pathString) {
if (pathString.startsWith("/")) {
return fs.makeQualified(new Path(basePath, pathString));
} else {
return super.path(pathString);
}
}
{code}
The code {{new Path(basePath, pathString)}} will simply return the pathString
when resolving because itself is absolute. If that's true, then the
{{ITestS3AFileSystemContract#path()}} is basically falling back to the base
method {{FileSystemContractBaseTest#path()}}. One possible solution to this is
to use unique test directory for each test method {{/test/$methodName}} in base
class while S3A contract tests uses {{/s3afilesystemcontract/test/$methodName}}.
# After we have patches fixing the 1st problem, the duplicate items i.e.
{{AmazonDynamoDBException: Provided list of item keys contains duplicates}} may
still happen if there is duplicates brought by {{S3AFileSystem#innerRename()}}.
It's possible that this is also caused by the 1st problem.
Anyway we need separate JIRAs for the above problems. We can get them in before
this one, though not related to this scope.
> S3Guard: DynamoDBMetadataStore#move() could be throwing exception due to
> BatchWriteItem limits
> ----------------------------------------------------------------------------------------------
>
> Key: HADOOP-13934
> URL: https://issues.apache.org/jira/browse/HADOOP-13934
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: HADOOP-13345
> Reporter: Rajesh Balamohan
> Assignee: Mingliang Liu
> Priority: Minor
> Attachments: HADOOP-13934-HADOOP-13345.000.patch,
> HADOOP-13934-HADOOP-13345.001.patch, HADOOP-13934-HADOOP-13345.002.patch,
> HADOOP-13934-HADOOP-13345.003.patch, HADOOP-13934-HADOOP-13345.004.patch,
> HADOOP-13934-HADOOP-13345.005.patch
>
>
> When using {{DynamoDBMetadataStore}} with a insert heavy hive app , it
> started throwing exceptions in {{DynamoDBMetadataStore::move}}. But just with
> the following exception, it is relatively hard to debug on the real issue in
> DynamoDB side.
> {noformat}
> Caused by: com.amazonaws.services.dynamodbv2.model.AmazonDynamoDBException: 1
> validation error detected: Value
> '{ddb-table-name-334=[com.amazonaws.dynamodb.v20120810.WriteRequest@ca1da583,
> com.amazonaws.dynamodb.v20120810.WriteRequest@ca1fc7cd,
> com.amazonaws.dynamodb.v20120810.WriteRequest@ca4244e6,
> com.amazonaws.dynamodb.v20120810.WriteRequest@ca2f58a9,
> com.amazonaws.dynamodb.v20120810.WriteRequest@ca3525f8,
> ...
> ...
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1529)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1167)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:948)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:661)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:635)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:618)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$300(AmazonHttpClient.java:586)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:573)
> at
> com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:445)
> at
> com.amazonaws.services.dynamodbv2.AmazonDynamoDBClient.doInvoke(AmazonDynamoDBClient.java:1722)
> at
> com.amazonaws.services.dynamodbv2.AmazonDynamoDBClient.invoke(AmazonDynamoDBClient.java:1698)
> at
> com.amazonaws.services.dynamodbv2.AmazonDynamoDBClient.batchWriteItem(AmazonDynamoDBClient.java:668)
> at
> com.amazonaws.services.dynamodbv2.document.internal.BatchWriteItemImpl.doBatchWriteItem(BatchWriteItemImpl.java:111)
> at
> com.amazonaws.services.dynamodbv2.document.internal.BatchWriteItemImpl.batchWriteItem(BatchWriteItemImpl.java:52)
> at
> com.amazonaws.services.dynamodbv2.document.DynamoDB.batchWriteItem(DynamoDB.java:178)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.move(DynamoDBMetadataStore.java:351)
> ... 28 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
