逻辑应用程序:具有并发控制的ServiceBus触发器导致窥视锁定超时

Question

几天后，我看到了在逻辑应用程序中使用ServiceBus触发器与“并发控制”功能相结合时的一些“新”行为。我有一个轮询触发器每5分钟检查一次队列。并将并发控件配置为最多5个实例，以不重载我的后端数据库。

在过去，当我将40条消息放在队列中时，它会旋转5个实例。当轮询间隔过去时，仍有3个实例在运行.然后触发器又旋转了2个实例，将运行中的实例总数带回到我配置的5阈值。

现在我看到触发器立即创建了40个实例。其中5人跑步，其余35人处于“等待”状态。当一个实例完成处理时，其中一个等待实例启动它的工作。听起来不错，你不觉得吗？不是所有的场景..。

​

​

当使用Peek-锁机制时，超时会在“等待”实例启动时开始计数。如果它必须等待超过5分钟(锁定超时最大)，锁是过期的。这将导致消息在队列中再次可用，从而为同一条消息启动一个新的“等待”实例。因此，最后，我得到了许多不必要的重复处理，甚至消息也因为达到了maxDeliveryCount限制而变得死气沉沉。

似乎找不到任何关于投票行为变化的信息吗？除了使用自动完成系统之外，还有谁能解决窥视锁问题？

更新07/08/2018:

确认这是为SplitOn触发器启用并发控制的新实现。一旦在您的Logic上启用了SplitOn，您就会得到这种行为。即使您再次禁用SplitOn，行为仍然是这样的。要“重置”您的Logic，您必须完全删除资源并重新部署它。

Answer 1

确认这是为SplitOn触发器启用并发控制的新实现。一旦在您的Logic上启用了SplitOn，您就会得到这种新的行为。即使您再次禁用SplitOn，行为仍然是这样的。要“重置”您的逻辑应用程序，您必须完全删除资源并重新部署它。

如果“等待运行”实现适合您的场景，但您仍然希望控制每次触发器运行时启动/等待的实例数量，则可以使用设置来控制最大“waitingRuns”。不幸的是，UI中还没有启用这个功能，所以您需要转到代码视图。目前，maximumWaitingRuns不能设置为1以下。

​

​

Answer 2

听起来是个真正的问题。由于锁定持续时间的最大值为5分钟，因此您别无选择，只能使用“自动完成”。

我的建议是有两个订阅或一个重复队列的主题。

主题订阅-消息将发送给两个订阅，在那里您可以使用一个订阅逻辑应用程序自动完成和另一个订阅跟踪消息。由于两个订阅将具有相同的消息，因此不会出现任何重复或丢失消息。

重复队列-您可以让Logic自动完成消息，并将其转换为第二个队列，在那里您可以跟踪消息。