[
https://issues.apache.org/jira/browse/HADOOP-15625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791673#comment-16791673
]
Steve Loughran commented on HADOOP-15625:
-----------------------------------------
sounds OK, I'll have a test too. Interesting that distcp failed though. We do
see intermittent failures of things, which are sometimes a sign of local
configs, but sometimes a sign of a deeper problem lurking somewhere
looking at the trace of how the error text :"DistCp failure: Job
job_local79261498_0009 has failed: NA" could creep in, it means the job
completed but not in successful state (i.e. failed, killed),. and no failure
info was set. Also looks like the failureInfo field isn't even serialized.
If you want to independently improve the output there from, say: log the job
status and for the message chose between failed/killed based on the final
state, happy to review that *in a separate patch*.
> S3A input stream to use etags/version number to detect changed source files
> ---------------------------------------------------------------------------
>
> Key: HADOOP-15625
> URL: https://issues.apache.org/jira/browse/HADOOP-15625
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 3.2.0
> Reporter: Brahma Reddy Battula
> Assignee: Ben Roling
> Priority: Major
> Attachments: HADOOP--15625-006.patch, HADOOP-15625-001.patch,
> HADOOP-15625-002.patch, HADOOP-15625-003.patch, HADOOP-15625-004.patch,
> HADOOP-15625-005.patch, HADOOP-15625-006.patch, HADOOP-15625-007.patch,
> HADOOP-15625-008.patch, HADOOP-15625-009.patch, HADOOP-15625-010.patch,
> HADOOP-15625-011.patch, HADOOP-15625-012.patch, HADOOP-15625-013-delta.patch,
> HADOOP-15625-013.patch, HADOOP-15625-014.patch, HADOOP-15625-015.patch,
> HADOOP-15625-015.patch, HADOOP-15625-016.patch
>
>
> S3A input stream doesn't handle changing source files any better than the
> other cloud store connectors. Specifically: it doesn't noticed it has
> changed, caches the length from startup, and whenever a seek triggers a new
> GET, you may get one of: old data, new data, and even perhaps go from new
> data to old data due to eventual consistency.
> We can't do anything to stop this, but we could detect changes by
> # caching the etag of the first HEAD/GET (we don't get that HEAD on open with
> S3Guard, BTW)
> # on future GET requests, verify the etag of the response
> # raise an IOE if the remote file changed during the read.
> It's a more dramatic failure, but it stops changes silently corrupting things.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
