Azure服务总线队列PeekBatch锁定
本文关键字:PeekBatch 锁定 队列 总线 服务 Azure | 更新日期: 2023-09-27 18:29:37
我在QueueClient
(Windows Azure Service Bus包2.1.2.0版)上使用PeekBatch(<messageCount>)
方法。
它第一次运行良好,并返回队列中存在的单个消息,但随后的调用什么也不返回。五分钟后,该电话将再次返回消息。
五分钟是BrokeredMessage
的最长锁定时间,所以我想知道PeekBatch
是否真的像在接收时一样锁定了这些消息,尽管据我所知,偷看不应该锁定。
我正试图构建一个MVC视图,以便能够看到队列中实际存在的内容,但这一个正在阻碍我。有人能对此提供任何指导吗?
更新:只有当我使用静态属性缓存QueueClient
时,才会出现这种情况。如果我每次都创建新的QueueClient
,那么PeekBatch
将按预期工作。我仍然不知道为什么重用QueueClient
会导致这种情况。不过,微软似乎建议重用QueueClient
,而不是每次都重新创建它,所以我在这里仍然不知所措。
QueueClient在某种程度上有所帮助。在Peek方法(Peek和PeekBatch)中,您可以简单地调用它们,或者您可以给出特定的序列号来检索特定序列号之后的特定消息。如果您只是简单地调用Peek,或者在您的情况下调用PeekBatch,而没有序列号,那么它将检索队列中的第一条或多条消息。一旦返回消息,QueueClient就会跟踪它提取的最后一个序列号。每个对Peek的后续调用都将获取队列中的下一条消息。这样做的目的是"浏览"消息,而不仅仅是每次都对队列中的第一条消息感兴趣。
所以,如果您在一个循环中反复调用peek,直到它没有返回消息,那么您基本上已经浏览了队列中的所有消息。
由于您调用PeekBatch时没有序列号,QueueClient会记住它得到的最后一个集合,那么下一个调用实际上会在它浏览的最后一条消息之后尝试得到下一个集合。这就是为什么当您重新创建QueueClient时,它似乎会重置。它在5分钟后自行重置的原因似乎很奇怪,但它可能只是在与队列上的Timeout操作相关的某个点之后清除浏览值。到那时,如果它是一个繁忙的队列,那么序列号无论如何都会非常遥远。
如果你真的只需要看第一条消息,那么只需要打一次peek。它只会返回第一条消息。如果每次都需要不断地提取第一条消息,请执行Peek(0)。如果你想先说每次10条消息,然后调用PeekBatch(0,10);这就像是说,给我前十条序列号大于0的消息。
重用QueueClient的指导是合理的。它对信息和事物进行各种缓存。你不想每次都重新创建它。