2016-10-05 4 views
1

У нас есть веб-приложение, которое обрабатывает внешние обратные вызовы. Чтобы изолировать наше приложение от внешней службы, мы используем azure blob для хранения данных обратного вызова (.json) и помещаем сообщение на шину Azure Service для последующей обработки службы обработки. Следующий код используется для записи данных в хранилище больших двоичных объектов:Azure blob service, random 404-not found errors

 var storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("MyStorage")); 
     var blobClient = storageAccount.CreateCloudBlobClient(); 
     var container = blobClient.GetContainerReference("containername"); 
     var dataFileName = Guid.NewGuid().ToString(); 
     var blockBlob = container.GetBlockBlobReference(dataFileName); 
     blockBlob.UploadText(data); 
     blockBlob.Properties.ContentType = "application/json"; 
     blockBlob.SetProperties(); 

     var connectionString = CloudConfigurationManager.GetSetting("serviceBusCS"); 
     var queueName = "MyQueue"; 
     var client = QueueClient.CreateFromConnectionString(connectionString, queueName); 

     var payload = new MyCustomMessage { 
      Id = dataFileName 
     }; 
     var message = new BrokeredMessage(payload); 
     client.Send(message); 

На стороне обработки, у нас есть веб-работа чтение сообщений один в то время и извлечения данных следующим образом:

  var storageAccount = CloudStorageAccount.Parse("MyCS"); 
      var blobClient = storageAccount.CreateCloudBlobClient(); 
      var container = blobClient.GetContainerReference("containername"); 
      var blockBlob = container.GetBlockBlobReference(message.Id); 
      if (blockBlob == null) { 
       return; 
      } 
      if (!blockBlob.Exists()) { 
       return; ==> FAILS HERE 
      } 
      // Process the message here... 
      // Once the processing is done, delete the blob 

Эта конструкция работает хорошо, но мы получаем 404-NotFound отныне (с пометкой FAILED HERE выше).

ВОПРОС

Единственный способ этот код может потерпеть неудачу, имея два сообщения с тем же именем файла: то есть тот же GUID, который почти невозможно, или я что-то не хватает? Любая идея, почему данные blob не могут быть найдены?

EDIT 1 Поиск пропавшего blob с портала Azure показывает, что на самом деле блоба нет. Не следует ли blockBlob.UploadText(data); бросать, если он не может записать данные в контейнер blob?

EDIT 2

Благодаря Джейсону для указания, где искать. Мы просканировали наши журналы и обнаружили, что блоб успешно записывается. Веб-работа запускается и обрабатывает сообщение, но через минуту, ровно через минуту мы видим, что веб-работа начинается с того, что пытается обработать одно и то же сообщение снова, и он не найдет blob, который ожидается, поскольку первый запуск очистит blob и удалил его.

ответ

1

Если клиентское приложение получает сообщение HTTP 404 (не найденное) с сервера, это означает, что объект, который клиент пытался использовать (например, сущность, таблица, блок-схема, контейнер или очередь), не существует в службе хранения. Для этого существует ряд возможных причин, таких как: • Клиент или другой процесс ранее удалил объект • Проблема авторизации доступа к общей подписке (SAS) • Клиентский код JavaScript не имеет разрешения на доступ к объекту • Сбой сети

Для получения дополнительной информации см. Storage Monitoring, Diagnosing and Troubleshooting Guide.

+0

Спасибо, Джейсон. Я бы ожидал, что 'blockBlob.UploadText (data);' throw, если он не сможет записать данные, не так ли? Как упоминалось в вопросе, мы генерируем новый файл для каждого полученного пакета данных, имена файлов - это GUID, поэтому никогда не может быть двух похожих сообщений, ссылающихся на один и тот же файл. – GETah

+0

Проделал еще несколько исследований, благодаря ссылке на мониторинг и диагностику. См. Мои правки. – GETah

+0

У вас включена функция аналитики хранилища? –