[jira] [Resolved] (HADOOP-14585) Ensure controls in-place to prevent clients with significant clock skews pruning aggressively

["Steve Loughran (Jira)" <ji...@apache.org>]

     [ 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: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org