AWS Lambda, подключенная к событию S3 ObjectCreated, возвращает «NoSuchKey: указанный ключ не существует:

Я загружаю файл с устройства Android в корзину S3 с помощью этого кода

TransferUtility trasnferManager = new TransferUtility(s3, context);
trasnferManager.upload(..,..,..);

После этого у меня есть лямбда-триггер, прикрепленный к событию S3: ObjectCreated.

Когда выполняется лямбда, я пытаюсь получить файл с помощью функции S3.getObject (). К сожалению, иногда я получаю сообщение об ошибке «NoSuchKey: указанный ключ не существует:». После этого лямбда повторяется несколько раз, успешно получает файл и продолжает его выполнение.

На мой взгляд, лямбда-функция выполняется до того, как файл в S3 станет доступным? Но это не должно происходить по замыслу. Триггер должен сработать после завершения загрузки файла на S3.

Согласно объявлению от 4 августа 2015 г.:

Корзины Amazon S3 в всех регионах обеспечивают согласованность чтения после записи для PUTS новых объектов и возможную согласованность для перезаписи PUTS и DELETES.

Согласованность чтения после записи позволяет извлекать объекты сразу после создания в Amazon S3.

Но до этого:

Все регионы, кроме Стандарт США (переименованного в Восток США (Северная Вирджиния)), поддерживали согласованность чтения после записи для новых объектов, загруженных на Amazon. S3.

Моя корзина находится в регионе Восток США (Северная Вирджиния) и создана до 4 августа 2015 г.. Не знаю, может ли это быть проблемой …

РЕДАКТИРОВАТЬ: 20.10.2016

Согласно документацииСОГЛАСОВАННОЕ ЧТЕНИЕ < Операция / strong> может вернуть НЕТ РЕЗУЛЬТАТА, даже если до нее были выполнены две или более операций ЗАПИСЬ.

В этом примере и W1 (запись 1), и W2 (запись 2) завершаются до начала R1 (чтение 1) и R2 (чтение 2). Для согласованного считывания R1 и R2 возвращают цвет = рубиновый. Для в конечном итоге согласованного чтения R1 и R2 могут возвращать цвет = красный, цвет = рубин или отсутствие результатов, в зависимости от количества прошедшего времени.

См. также:  Вероятный тайм-аут Terraform лямбда-вызова

«Последовательный

Укажите конечную точку, которую вы используете, и добавьте дополнительный код в свой вопрос. Это может помочь — forum.aws.amazon.com/ann.jspa?annID= 3112   —  person bpavlov    schedule 19.08.2016

Я использую s3.amazonaws.com. Я считаю, что это устарело, потому что, как говорят, корзины Amazon S3 во всех регионах обеспечивают согласованность чтения после записи без дополнительной информации.   —  person bpavlov    schedule 19.08.2016

У меня похожая проблема, но не всегда. Я обнаружил, что с большими файлами такое случается. У меня есть событие, запускающее лямбда, и большую часть времени лямбда затем пытается переместить файл и успешно. В файлах большего размера (38 МБ jpg) он сообщает, что их не существует, и дает сбой. Как только лямбда повторно инициализируется для повторной попытки из-за сбоя, она работает нормально. Кажется смешным, что событие запускается до того, как файл станет доступным.   —  person bpavlov    schedule 06.09.2016

То же самое. Даже с небольшими файлами. @Joel   —  person bpavlov    schedule 08.12.2016

Кому-нибудь уже удалось это исправить?   —  person bpavlov    schedule 08.12.2016

+1, мы используем сингапурский центр, и он сталкивается с этой проблемой для новых файлов. В среднем это происходит один раз на каждые 500 загруженных файлов.   —  person bpavlov    schedule 06.01.2017

Понравилась статья? Поделиться с друзьями:
IT Шеф
Комментарии: 2
  1. bpavlov

    Иногда, когда файлы большие, они загружаются с использованием многостраничной загрузки, и она отправляет триггер лямбда-выражению до того, как файл будет полностью загружен. Предположительно, это связано с событием, запускающим лямбда-функцию. В поле события лямбда-функции убедитесь, что вы добавили к событию как размещение, так и полную загрузку нескольких частей.

    Я не знал, что это был вариант, но обязательно изучу это. person bpavlov; 04.01.2017

    Эта проблема не связана с размером файла. Бывает даже на небольших файлах (~ 200кБ). person bpavlov; 17.01.2017

    @Joel, можете ли вы обновить, что произошло, когда вы добавили к событию загрузку из нескольких частей. Спасибо person bpavlov; 12.07.2017

    @AhmedAbouhegaza, к сожалению, я больше не работаю над проектом, поэтому маловероятно, что у меня будет возможность проверить это. Тебе с этим повезло? person bpavlov; 13.07.2017

    @Joel Я столкнулся с проблемой, и я добавил multipart к событию, и это сработало для меня. Это случилось даже с небольшими файлами. person bpavlov; 13.07.2017

    @AhmedAbouhegaza, к сожалению, нет. Возможно, стоит проверить, выполняете ли вы операции OVERWRITE PUT. В этом случае согласованность чтения после записи является СОБСТВЕННЫМ, и это может вызвать ошибки. P.S .: Я таких операций не выполняю и все равно возникают те же ошибки. person bpavlov; 13.07.2017

  2. bpavlov

    Для защиты от этой проблемы можно использовать официант S3 SDK. После получения уведомления мы можем убедиться, что объект действительно находится там. Например, для AWS JavaScript SDK вы можете использовать следующий фрагмент:

    s3.waitFor("objectExists", {
        Bucket: "<bucket-name>",
        Key: "<object-key>"
    }, callback);
    

    Обратите внимание, что waitFor увеличит время выполнения вашей лямбды, а это означает, что вам нужно будет увеличить время ожидания. Согласно документации, проверка будет производиться каждые 5 секунд до 20 раз. Таким образом, установка тайм-аута примерно на 1 минуту должна помочь избежать исключений тайм-аута выполнения.

    Ссылка на документацию: AWS JavaScript SDK S3 Class </ а>

Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: