Сведения об исключениях в хранилище таблиц Azure - PullRequest
3 голосов
/ 15 ноября 2011

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

После долгих поисков в интернете сообщение на http://blogs.msdn.com/b/partlycloudy/archive/2009/12/16/development-storage-logging.aspx показывает, как включить ведение журнала. Это заполняет файл журнала ошибок гораздо более полезной информацией. Вероятно, не стоит оставлять этот журнал на постоянной основе, и проверка этого файла каждый раз, когда у меня возникает проблема, не идеальная ситуация.

Есть много сообщений об использовании Fiddler для просмотра реальных запросов и ответов, но я не могу заставить это работать должным образом. Я настроил строку подключения для подключения через прокси-сервер Fiddler (мне пришлось вручную добавить имя хоста ipv4.fiddler в файл hosts, иначе оно не будет разрешено - что Fiddler должен делать автоматически). Я вижу соединения для развертывания, но не соединения для каких-либо запросов. Я попытался запустить Fiddler от имени администратора, но все равно получил те же результаты.

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

Ответы [ 4 ]

5 голосов
/ 15 ноября 2011

Как правило, вы получаете сообщения об ошибках неверных входов, если вы пытаетесь использовать операцию, которая не поддерживается службой.Имейте в виду, что полный набор операций LINQ (сортировка, min, max и т. Д.) Недоступен в службе (хотя они могут быть вычислены локально).Ваш первый шаг в устранении неисправностей должен состоять в том, чтобы посмотреть на реальные операции, которые вы пытаетесь.Если вы используете что-то отличное от .Select () или .Where (), есть большая вероятность, что оно в настоящее время не поддерживается.

Edit : как только я написал это, ястолкнулся с подобной ошибкой.Поскольку я уже знаю, какие операции поддерживаются, я подумал, что покажу вам код, который использовал для устранения неполадок:

void Main()
{
    var acct = CloudStorageAccount.DevelopmentStorageAccount;

    var client = acct.CreateCloudTableClient();
    var ctx = client.GetDataServiceContext();
    ctx.IgnoreMissingProperties = true;

    var table = "tl36f6e92d94954f168ade0be6a547c0ce";

    //build query
    var q = ctx.CreateQuery<Foo>(table)
        .Where(e => e.RowKey.CompareTo(2) < 0) //this query fails
        .Take(10);

    //Dump URI to inspect
    ((DataServiceQuery)q).RequestUri.Dump();

    //dump results
    q.Dump();
}


[System.Data.Services.Common.DataServiceKey("PartitionKey", "RowKey")]
class Foo
{
    public string PartitionKey { get; set; }
    public string RowKey { get; set; }
    public string Whatever { get; set; }
}

Я поместил это в LINQPad (лучший инструмент из когда-либо созданных) и просто посмотрел на URI.Стало ясно, что сравнение, которое я проводил, ожидало строку и сравнивалось как целое число.Я, конечно, упростил реальный запрос, но моя точка зрения остается в силе.Я все время использую этот инструмент для моделирования своих запросов и проверки того, что на самом деле происходит.

4 голосов
/ 27 февраля 2012

Если вы добавите «ipv4.fiddler» в файл хостов, он разрешит localhost до использовать Fiddler и, следовательно, игнорирует настройку прокси, так как это локальный адрес. Ответ не в том, чтобы добавить «ipv4.fiddler» к хостам. Существует решение проблемы разрешения DNS, с которой вы столкнулись ...

Когда вы запускаете Fiddler, он устанавливает прокси WinINET для вошедшего в систему пользователя на 127.0.0.1:8888. Однако Dev Fabric устанавливает пул приложений IIS для работы в качестве NETWORK SERVICE, поэтому он не знает конфигурации прокси WinINET от Fiddler и, следовательно, не маршрутизирует HTTP-запросы через Fiddler. Поэтому мы получаем ошибку разрешения DNS при использовании строки подключения хранилища Azure: "UseDevelopmentStorage = true; DevelopmentStorageProxyUri = http://ipv4.fiddler".

Так что попробуйте запустить это из командной строки VS:

битадмин / утилит / SETIEPROXY NETWORKSERVICE MANUAL_PROXY 127.0.0.1:8888 NULL

так что теперь NETWORK SERVICE использует Fiddler в качестве прокси, разрешает ipv4.fiddler на localhost и отслеживает весь HTTP-трафик в эмулятор хранения dev и из него.

0 голосов
/ 22 июня 2016

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

https://www.nuget.org/packages/AzureStorageExceptionParser/

Использование:

Попробуйте

{

// Сделать запрос к хранилищу таблиц Azure (Blob, Table, Queue, ..)

}

catch (StorageException storageException)

{

// Метод расширения GetHttpStatusCode дает вам HttpStatusCode, встроенный в StorageException

INT? httpStatusCode = storageException.GetHttpStatusCode ();

// Метод расширения GetFailedOperationIndex дает индекс неудачной операции в пакетной операции Azure Table

int failedOperationIndex = storageException.GetFailedOperationIndex ();

}

0 голосов
/ 21 февраля 2013

Я только что получил эту ошибку и хотел бросить свои 2 цента, надеясь сэкономить кому-то еще несколько минут ... У меня был обнуляемый Guid в моем POCO, и до сих пор ни одна из записей не заполнила это значение ни за чтои поэтому, когда я позвонил:

_repository.Find(f => f.PartitionKey == request.CompanyPartitionKey() && f.MyNullGuid == null);

, это выдало ту же ошибку, потому что до тех пор, пока экземпляр не получил значение без значения NULL, хранилище таблицы вообще не помещало этот столбец ... Итак, яполучал «Неверный ввод» из-за того, что я не делал, а потому, что Table Storage никогда не помещал мой обнуляемый столбец до тех пор, пока это не гарантировало запись.

Исправление: я изменил свой нулевой guid на ненулевой иизменил мой чек на Guid.Empty ... Тьфу ...

...