为什么Azure逻辑“当队列中接收到消息时（peek lock）”、“下一个可用”等了这么长时间才提取队列消息？
我的设置：
- 我已创建启用会话的Azure服务总线队列。
会话id=下一个可用的会话id间隔=15，频率=秒- 如果我的Azure Logic App中的步骤成功，我将
完成队列中的消息，否则我将死信队列中的消息
我的结果：
- Azure逻辑应用一次拾取一个队列消息并处理它，但在拾取下一条消息之前，要等待整个
锁定持续时间（在我的例子中为1分钟）。 - 注意：当我将会话id设置为特定的会话id时，它不会等待，而是立即处理消息
我的问题:
- 我希望Azure Logic应用程序在会话id可用时，在完成后立即处理更多队列消息。这可能吗？我是否缺少一个设置来告诉Azure Logic应用程序不要等待整个锁定期
共有1个答案
您的邮件是否具有相同的SessionId？
在这种情况下，我认为你的逻辑应用持有会话锁，所以你需要使用“在队列中关闭会话”任务。
如果您有多条具有相同SessionId的消息，那么根据我的简单测试，在接收下一条具有相同SessionId的消息之前，会话锁似乎会保持一分钟。关闭会话会立即处理同一会话中的下一条消息。
我在生产使用中也遇到过类似的情况，我必须等待一段时间，然后将具有相同SessionId的所有消息拉到一起，但是如果有多个会话正在进行，它可以很好地运行并发逻辑应用程序，这在我的测试设置中也是一样的。
-
我的设置： 我创建了一个没有启用会话的Azure服务总线队列 我有一个使用触发器 触发器间隔为 我的结果： 我正在以超过15秒的速度将消息放入队列 我的Azure逻辑应用触发器一次拾取多个队列消息，比每15秒拾取一条消息快得多 我的问题： 此连接器的触发器是否设计为一次拾取多条排队消息（在？）
-
使用启用会话（消息排序）的Azure ServiceBus队列，我的会话需要持续几分钟到几个小时。 为此，我将QueueClient配置如下： 并按如下方式开始接收消息： 在几次（1到6次之间）成功（几乎是瞬时的）消息接收回调之后——无论是对于新会话还是现有会话，接收处理程序都会停止触发。使用，我可以看到位于servicebus队列上的消息。有趣的是，它们都有一个DeliveryCount=1。过
-
有人能解释一下Android中的消息队列是什么吗？是正在运行的进程列表吗？我找不到很好的消息来源来解释。 我之所以这样问，是因为我读到了类视图的方法帖子。 邮政 导致将Runnable添加到消息队列中。runnable将在用户界面线程上运行。 提前谢谢你。
-
为什么已经拥有了共享内存时需要消息队列呢？ 这将是多种原因，让我们将其分解为多个点来简化 - 据了解，一旦消息被一个进程接收到，它将不再可用于任何其他进程。 而在共享内存中，数据可供多个进程访问。 如果想使用小信息格式进行通信。 当多个进程同时进行通信时，共享内存数据需要同步保护。 使用共享内存的写入和读取频率很高，那么实现功能将会非常复杂。 在这种情况下不值得使用。 如果所有的进程不需要访问共享
-
一、消息模型 点对点 发布/订阅 二、使用场景 异步处理 流量削锋 应用解耦 三、可靠性 发送端的可靠性 接收端的可靠性 参考资料 一、消息模型 点对点 消息生产者向消息队列中发送了一个消息之后，只能被一个消费者消费一次。 发布/订阅 消息生产者向频道发送一个消息之后，多个消费者可以从该频道订阅到这条消息并消费。 发布与订阅模式和观察者模式有以下不同： 观察者模式中，观察者和主题都知道对方的存在；
-
一个线程会从消息队列中收取消息，另一个线程会定时给消息队列发送普通消息和紧急消息 一个线程会从消息队列中收取消息，另一个线程会定时给消息队列发送普通消息和紧急消息 源码/* * Copyright (c) 2006-2018, RT-Thread Development Team * * SPDX-License-Identifier: Apache-2.0 * * Change Logs: *