[
https://issues.apache.org/jira/browse/HADOOP-14585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran resolved HADOOP-14585.
-------------------------------------
Resolution: Won't Fix
> Ensure controls in-place to prevent clients with significant clock skews
> pruning aggressively
> ---------------------------------------------------------------------------------------------
>
> Key: HADOOP-14585
> URL: https://issues.apache.org/jira/browse/HADOOP-14585
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 3.0.0-beta1
> Reporter: Sean Mackrory
> Priority: Minor
>
> From discussion on HADOOP-14499:
> {quote}
> bear in mind that we can't guarantee that the clocks of all clients are in
> sync; you don't want a client whose TZ setting is wrong to aggressively prune
> things. Had that happen in production with files in shared filestore. This is
> why ant -diagnostics checks time consistency with temp files...
> {quote}
> {quote}
> temp files work on a shared FS. AWS is actually somewhat sensitive to clocks:
> if your VM is too far out of time then auth actually fails, its ~+-15
> minutes. There's some stuff in the Java SDK to actually calculate and adjust
> clock skew, presumably parsing the timestamp of a failure, calculating the
> difference and retrying. Which means that the field in SDKGlobalConfiguration
> could help identify the difference between local time and AWS time.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
