Вызов DocumentDB зависает

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

Когда я проверяю коллекцию, я вижу, что создается новый человек, но мой код просто зависает, когда я делаю второй вызов, чтобы вставить человека в коллекцию. Есть идеи, почему мой код зависает? Я не включаю весь код для экономии места, например. GetDatabaseAsync(), GetCollectionAsync() и т. д. работают.

using (client = new DocumentClient(new Uri(endPointUrl), authorizationKey))
{
   //Get the database
   var database = await GetDatabaseAsync();

   //Get the Document Collection
   var collection = await GetCollectionAsync(database.SelfLink, "People");

   string sqlQuery = "SELECT * FROM People f WHERE f.id = \"" + user.PersonId + "\"";

   dynamic doc = client.CreateDocumentQuery(collection.SelfLink, sqlQuery).AsEnumerable().FirstOrDefault();

   if (doc == null)
   {
      // User is not in the database. Add user to the database
      try
      {
         **// This is where the code is hanging. It creates the user in my collection though!**
         await client.CreateDocumentAsync(collection.DocumentsLink, user);
      }
      catch
      {
         // Handle error
      }
   }
   else
   {
      // User is already in the system.
      user = doc;
   }
}

Возможно ли, что код зависает, потому что я пытаюсь запросить и вставить документ внутри одного и того же оператора USING.

Не лучше ли мне создать новый экземпляр клиента и создать отдельный блок для обработки документа INSERT?


azure-cosmosdb
person Sam    schedule 22.11.2014    source источник
comment
Я не вижу здесь никаких сногсшибательных красных флажков. Повторное использование клиента должно быть быстрее - это позволяет избежать повторного рукопожатия с сервером базы данных. Можете ли вы дать мне представление о том, как выглядит временной профиль для этого? Сколько времени занимает первоначальный запрос? Сколько времени занимает создание документа?   -  person Andrew Liu    schedule 23.11.2014
comment
После публикации этого вопроса я решил упростить свою логику, поэтому я просто сделал часть INSERT. Я все еще получаю тайм-аут. См. этот пост: stackoverflow.com/questions/27086097/ Как получить профиль синхронизации? Вы имеете в виду, поместите в мой код переменную DateTime, чтобы зафиксировать точное время, когда код выполняет каждую строку, или есть инструмент, который я могу использовать для захвата временного профиля? Также есть идеи, почему DocumentDB не возвращает ответ после CreateDocumentAsync()?   -  person Sam    schedule 23.11.2014
comment
Есть ли в вашем стеке вызовов место, где вы вызываете асинхронный метод из неасинхронного метода?   -  person Aman B    schedule 28.01.2017

Ответы (2)


arrow_upward
6
arrow_downward

Если вызов асинхронного метода зависает, это обычно происходит потому, что он вызывается синхронно, вызывая его с помощью .Wait() или .Result вместо await ing. Вы не указали свой телефонный код, поэтому укажите его здесь.

Вариант 1. Не вызывайте асинхронный метод синхронно. Это правильный подход.

Вариант 2: вы должны использовать .ConfigureAwait(false) в асинхронных вызовах DocDB, если вы вызываете этот метод синхронно. Попробуй это:

var database = await GetDatabaseAsync()**.ConfigureAwait(false)**;
...
var collection = await GetCollectionAsync(database.SelfLink, "People")**.ConfigureAwait(false)**;
...
await client.CreateDocumentAsync(collection.DocumentsLink, user)**.ConfigureAwait(false)**;

Дополнительные сведения о ConfigureAwait

person Prasanna Narayanasamy    schedule 15.03.2015
comment
Сначала мы сделали то же самое для нашего проекта Azure Service Fabric. Теперь мы преобразовали его в веб-приложение, теперь тот же код занимает слишком много времени. - person AstroBoy; 25.02.2020

arrow_upward
4
arrow_downward

Кажется, в клиентском SDK DocumentDB есть ошибка. Попробуйте использовать client.CreateDocumentAsync(collection.DocumentsLink, user).Wait() вместо await client.CreateDocumentAsync(collection.DocumentsLink, user)

ОБНОВЛЕНИЕ: это, скорее всего, было исправлено в последнем SDK, так как я больше не могу его воспроизвести.

person Arnab Chakraborty    schedule 04.12.2014
comment
Кажется, это все еще происходит, они еще не исправили это? - person Jonathan; 21.09.2017