Очень редкая ошибка 400 неверных запросов при отправке в хранилище больших двоичных объектов Azure

#c# #http-status-code-400 #azure-blob-storage

Вопрос:

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

The remote server returned an error: (400) Bad Request.

Рассматриваемый код C # выглядит следующим образом:

 public void Upload(string fileName, T entity)
{
    try
    {
        var blockBlob = _blobContainer.GetBlockBlobReference(fileName);
        using (var stream = _serializer.Serialize(entity))
        {
            blockBlob.UploadFromStream(stream);
        }
    }
    catch (Exception ex)
    {
        var json = JsonConvert.SerializeObject(entity).SubstringSafe(0, 500);
        _logger.Error("Error uploading object '{0}' of type '{1}' to blob storage container '{2}'; entity='{3}'; error={4}",
            fileName,
            typeof(T).Name,
            _containerName,
            json,
            ex.CompleteMessage());
        throw;
    }
}

Это fileName может быть что-то вроде «4110 GetNodesForPathAnalysis» (который работает в других обстоятельствах), и _containerName это может быть «segmentedids» (который также работает в других обстоятельствах). Я знаю, что обычной причиной этой ошибки 400, которая несколько раз меня беспокоила, является имя контейнера или большого двоичного объекта, которое нарушает правила, но, похоже, здесь это не так.

Ошибка носит временный характер — если я обновлю страницу, на которой она отображается, объект (с тем же контейнером и именем файла) будет правильно загружен в хранилище больших двоичных объектов Azure.

Есть предложения?

1. я бы использовал блок повторных попыток с временной ошибкой, msdn.microsoft.com/en-us/library/hh680901 (v=pandp.50).aspx

2. @Tony — я попробую и опубликую ответ здесь.

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

Ответ №1:

Вы можете настроить сведения о классе BlobRequestOptions следующим образом со стратегией повторных попыток и таймаутом —

 //set the blob upload timeout and retry strategy
BlobRequestOptions options = new BlobRequestOptions();
options.ServerTimeout = new TimeSpan(0, 180, 0);
options.RetryPolicy = new ExponentialRetry(TimeSpan.Zero, 20);

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

http://sanganakauthority.blogspot.com/2014/07/upload-large-files-to-azure-block-blob.html

Если асинхронность не требуется, вы можете заставить ее работать синхронно. Надеюсь, это поможет.