StartCopyFromBlobAsync не поддерживает целевое AccessCondition, если срок аренды бесконечен

Question

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

1. Создайте пустой целевой блоб, если блоб не существует
2. Получите регулярную 30-секундную аренду (которую я автоматически возобновляю) для BLOB-объекта с leaseId
3. Используйте leaseId для создания объекта AccessCondition
4. Передайте объект AccessCondition в StartCopyFromBlobAsync как destAccessCondition

Фактический результат: удаленный сервер возвратил ошибку: (412) Идентификатор аренды совпадает, но указанная аренда должна быть арендой на неограниченный срок.

Есть ли способ обойти эту проблему и скопировать блоб без бесконечной аренды.

Answer 1

На основании документации here, невозможно инициировать операцию копирования большого двоичного объекта, если конечный большой объект имеет конечную аренду.

Так что, если вы хотите использовать опцию аренды, это будет бесконечная аренда блоба.

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

Затем вы постоянно проверяете статус копии целевого BLOB-объекта. После того, как BLOB-объект полностью скопирован, вы можете просто прекратить аренду BLOB-объекта. Теперь есть вероятность (как вы упомянули), что ваша копируемая виртуальная машина может выйти из строя. В этом случае, как только виртуальная машина копирования вернется в оперативный режим, вы снова начнете проверять статус копии. Также максимальное время, отведенное для операции копирования, составляет 2 недели. Если капля не будет скопирована в течение 2 недель, вы можете просто прекратить аренду этого блоба. Обратите внимание, что вам не нужен минимальный идентификатор при нарушении аренды на BLOB-объект.

Answer 2

Спасибо за ваше решение Гаурав. Это очень странно, что любой может нарушить договор аренды. Вот решение, с которым я решил пойти.

Вместо того, чтобы использовать аренду для BLOB-объектов, я проверяю статус 409 (HttpStatusCode.Conflict). Если 2 параллельных потока пишут в один и тот же BLOB-объект, один из них получит конфликт 409. Я поместил ожидание в этот второй параллельный поток, который получил 409 в течение небольшого промежутка времени (так как я знаю размер большого двоичного объекта, который нужно скопировать), и проверяю метаданные на большом двоичном объекте (progress = "done"). Более ранний поток, выполняющий копирование, установит эти метаданные после завершения копирования. Я копирую очень маленькие капли, так что этот подход будет работать для меня. Если время ожидания ожидания появления метаданных истекло, я не могу выполнить второй запрос, чтобы пользователь мог повторить попытку. Я делаю это в предположении, что лучше быстро потерпеть неудачу и позволить пользователю повторить попытку, чем ждать бесконечно.