Очередь служебной шины Azure Блокировка PeekBatch?
Я использую метод PeekBatch(<messageCount>) в QueueClient (пакет служебной шины Windows Azure 2.1.2.0).
Он отлично работает в первый раз и возвращает мое единственное сообщение, которое существует в моей очереди, но последующие вызовы не возвращают ничего. Через пять минут вызов снова вернет сообщение.
Пять минут - это максимальное время блокировки на BrokeredMessage, поэтому мне интересно, действительно ли PeekBatch блокирует такие сообщения, как это происходит при приеме, даже если подглядывание не должно блокироваться, насколько я знаю.
Я пытаюсь создать MVC-представление, чтобы видеть, что на самом деле сидит в моей очереди, но этот мешает. Может ли кто-нибудь дать какие-либо рекомендации по этому поводу?
Обновить. Это происходит только тогда, когда я кэширую свой QueueClient с помощью статического свойства. Если я создаю QueueClient каждый раз, PeekBatch работает так, как ожидалось. Я до сих пор не знаю, почему это повторяет использование QueueClient. Microsoft, похоже, рекомендует повторно использовать QueueClient хотя, вместо того, чтобы воссоздавать его каждый раз, поэтому я все еще здесь не понимаю.
QueueClient в некоторой степени полезен. В методах Peek (Peek и PeekBatch) вы можете просто вызвать их или указать определенный порядковый номер для получения определенного сообщения после определенного порядкового номера. Если вы просто вызываете Peek или в вашем случае PeekBatch, без порядкового номера, он будет извлекать самое первое сообщение или сообщения в очереди. Когда сообщение возвращается, QueueClient отслеживает последний порядковый номер, который он вытащил. Каждый последующий вызов Peek будет получать следующее сообщение в очереди. Идея состоит в том, что вы "просматриваете" сообщения и не просто интересуетесь первым сообщением в очереди каждый раз.
Итак, если вы были в цикле и многократно нажимали peek, пока он не вернул сообщение, вы, по сути, просмотрели все сообщения в очереди.
Поскольку вы вызываете PeekBatch без порядкового номера, QueueClient запоминает последний набор, который он получил, тогда следующий вызов фактически попытается получить следующий набор после последнего просматриваемого сообщения. Вот почему, когда вы воссоздаете QueueClient, это выглядит как reset. Причина, по которой он казался reset на своем собственном уровне через 5 минут, кажется странным, но, возможно, просто очистка значений браузера после некоторого момента, связанного с операцией таймаута в очереди. К тому времени порядковый номер был бы довольно далеко, если бы он был занятой очередью.
Если вам нужно действительно посмотреть только на первое сообщение, тогда вызовите peek только один раз. Он вернет только первое сообщение. Если вам нужно постоянно вытаскивать первое сообщение каждый раз за Peek (0). Если вы хотите, чтобы первые сказали 10 сообщений каждый раз, тогда вызывается PeekBatch (0, 10); это будет похоже на то, что я даю первые десять сообщений с порядковым номером, большим 0.
Рекомендации по повторному использованию QueueClient звучат. Он делает все виды кеширования информации и вещей. Вы не хотите, чтобы каждый раз его воссоздавать.
