[
https://issues.apache.org/jira/browse/HADOOP-19527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17941852#comment-17941852
]
Ahmar Suhail commented on HADOOP-19527:
---------------------------------------
Ok able to reproduce, it happens when you do
<property>
<name>fs.s3a.encryption.algorithm</name>
<value>SSE-KMS</value>
</property>
<property>
<name>fs.s3a.bucket.bucket.encryption.key</name>
<value>KEY</value>
</property>
and run the whole AbstractContractVectoredReadTest. It'll pass if you run just
testVectoredReadAfterNormalRead().
So guessing a previous test is caching this data in AAL, looking some more. Do
you think this is still a blocker?
> S3A: testVectoredReadAfterNormalRead() failing with 412 response from S3
> ------------------------------------------------------------------------
>
> Key: HADOOP-19527
> URL: https://issues.apache.org/jira/browse/HADOOP-19527
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 3.5.0, 3.4.2
> Reporter: Steve Loughran
> Assignee: Ahmar Suhail
> Priority: Blocker
>
> This is surfacing on a bucket using versionid for change detection: block
> reads are failing in the test
> {{ITestS3AContractAnalyticsStreamVectoredRead.testVectoredReadAfterNormalRead()}}
> {code}
> Caused by: software.amazon.awssdk.services.s3.model.S3Exception: At least one
> of the pre-conditions you specified did not hold (Service: S3, Status Code:
> 412, Request ID: 0AN2EB8QXC75HH0T, Extended Request ID:
> U5l/UnIF4n3NO1mrZVzS2vv72F3LgUoVJxR4XodUSaTWCerfjmmpH45CbFGKkTkfgfnykwzseGo=)
> at
> software.amazon.awssdk.services.s3.model.S3Exception$BuilderImpl.build(S3Exception.java:104)
> {code}
> * this is the normal readFully() call, before the vectored one
> * it worked last week
> * also found on branch-3.4 before the SDK update, so not an issue caused by
> the SDK unless my maven repo is badly contaminated
> * seems unrelated to versioning -still there when disabled.
> * applies on unversioned s3 express store too.
> About the main way I could see this surface is if the test file is less than
> the actual length of file created, so the GET is rejected for reading off the
> end (the openfile passes in the length to save the HEAD)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
