Azure服务总线-PeekBatchAsync返回的消息比预期的少
在Azure服务总线主题中，我有一个包含1000多条消息的订阅。这些消息由worker角色使用。出于监视目的，我想查看前10条消息，看看哪种消息正在等待处理。为了完成该任务，我创建了一个subscriptionclient，并调用方法PeekBatchAsync。奇怪的行为是，有时PeekBatchAsync返回的消息少于10条（即2条或4条）。
Dim subscriptionClient As SubscriptionClient = messagingFactory.CreateSubscriptionClient(topicName, subscriptionName)
Dim messages = Await subscriptionClient.PeekBatchAsync(10)
更多信息以澄清上下文：
- 我确信订阅包含超过1000条消息
- 创建主题时使用EnablePartitioning=True
- 我正在使用库Microsoft.ServiceBus v.2.3.4.0
- 我正在使用会话
- 大多数时候我得到的消息数量是正确的(10)，有时我得到的消息更少。我不知道复制此问题的确切条件是什么
我的问题是：为什么有时方法返回的消息比预期的少？
共有1个答案
我想Azure-ServiceBusReceiveBatch-方法的文档也适用于PeekBatchAsync。基本上写的是：最大值。可能会返回的消息数（在您的情况下为10)，但这不是保证。
当使用两个参数(int messageCount,TimeSpan serverwaittime)应用重载时，我体验到了更好的结果，在这里可以定义等待时间。
-
我有一个windows服务，它侦听Azure服务总线队列消息，以便从我的WebApi应用程序分发处理。此外，我还需要处理重复性任务（每晚/每周），我认为最好使用相同的系统来处理这些任务。 例如，假设我有一个“CleanupDb”队列，每天午夜删除过时的DB节点： 理论上这应该行得通，但我觉得我错过了一个更明显的处理方法。有没有更好的办法？
-
我正在尝试在Azure中构建一个简单的WebAPI REST服务，后端有一个服务总线队列工作器。我可以从Web API向工作人员发送一条消息。然而，我试图发送更多的信息，只是为了看看一切是如何运作的。因此，我创建了一个简单的控制器，如下所示： 当我呼叫控制器时，我只收到工作人员接收到的大约1/2的消息。其余的似乎都被放弃了。
-
我有一个azure功能，每1分钟触发一次。该函数创建如下所示的MessageReceiver 处理后，将使用完成消息，并使用关闭messageReceiver。 该函数第一次运行时最多从订阅获取100条消息，但在下一次运行时，它只获取0或1条消息，无论订阅中可用的消息数量如何（Service Bus Explorer显示订阅中有超过10条消息）。因此，即使有消息可用，ReceiveAsync似乎也
-
我在Azure中托管了两个云服务辅助角色，一个使用NServiceBus（Azure服务总线传输）消耗消息，另一个生成消息。 昨天，我部署了一个新版本的生产者工作者角色，而队列中仍然有大量消息，因为我们正在处理早上遗留下来的大量消息。当生产者启动时，它似乎已经清空（或者可能重新创建）队列，许多重要的生产消息丢失。这似乎很奇怪，但日志显示，大约在生产者角色启动时，消费者没有处理进一步的消息，我们知道
-
我正忙着研究Azure服务总线。我想用它来代替我们使用多个请求的系统。 然而，我看不出人们是如何对您排队的消息做出响应的？ 我可能误解了服务总线的使用方式吗？这是火灾和忘记类型的消息吗？
-
我在Azure Service Bus中使用代理消息传递（主题/订阅），我很好奇如何（或者是否）使用SSL保护通信。