Разница между временем запроса и текущим временем слишком велика

Question

Я загружаю и удаляю файлы из ведра S3. Ведро имеет около 50000 файлов. После загрузки и удаления каждых 10000 или нечетных файлов я получаю эту ошибку.

File "/Library/Python/2.7/site-packages/boto/s3/key.py", line 544, in delete 
    headers=headers) 
    File "/Library/Python/2.7/site-packages/boto/s3/bucket.py", line 760, in delete_key 
    query_args_l=None) 
    File "/Library/Python/2.7/site-packages/boto/s3/bucket.py", line 779, in _delete_key_internal 
    response.reason, body) 
boto.exception.S3ResponseError: S3ResponseError: 403 Forbidden 
<?xml version="1.0" encoding="UTF-8"?> 
<Error><Code>RequestTimeTooSkewed</Code><Message>The difference between the request time and the current time is too large.</Message><RequestTime>Sun, 07 Dec 2014 20:09:54 GMT</RequestTime><ServerTime>2014-12-07T21:09:56Z</ServerTime><MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds> 

У меня уже есть NTP, работающий на Mac, который синхронизируется с time.apple.com. Что еще я могу сделать, чтобы это ушло? Есть ли более эффективный способ удаления большого количества файлов/ключей в ведро S3, кроме как сделать четкое? Соответствующий код блок:

   try: 
        f.get_contents_to_filename(fname) 
        if (choice=="y"): f.delete() 
       except OSError,e: 
        print e 

Answer 1

Гадать, может быть бота кэш времени, и генератор в вашем макинтоше неточен в то же время.

Попробуйте «Delete Multiple Objects« API-интерфейс, предоставляемый AWS S3, это более эффективный способ удаления многих объектов. В boto это «boto.s3.bucket.Bucket.delete_keys».

Answer 2

Иногда мы наблюдаем эту ошибку, хотя машины, выполняющие код, определенно синхронизируются с NTP и используют часовой пояс UTC. Смещение, которое мы видим в сообщении об ошибке, может составлять 30 минут.

Смотрите здесь для некоторого наблюдения и предложение, как исправить это в Python с использованием тайм-аута декоратора:

http://www.saltycrane.com/blog/2010/04/using-python-timeout-decorator-uploading-s3/

В комментариях, есть еще одно предложение, чтобы исправить это, используя более короткие таймауты сокетов.

Мое предположение о первопричине: время от времени запрос зависает в очереди на стороне Амазонки, а затем обрабатывается с большой задержкой. Некоторые проверки безопасности вызывают и предотвращают выполнение и вместо этого отвечают на ошибку. Поэтому, вероятно, невозможно «исправить» на нашей стороне.