jakarta-ee - 在 MDB 中控制并发和消耗

Question

是否有任何标准方法来控制 MDB 中的并发和消耗？我能找到的每个建议似乎都是特定于应用程序服务器或资源适配器的(例如 maxSession @ActivationConfigProperty )。

问题™

我们在双节点 JBoss 设置 (EAP 6.3) 上运行一些相对繁重的分析作业，并希望并行化作业并对并发作业数量施加上限，这样我们就不会淹没数据库服务器。作业从 Web 前端启动，并且应该在有空闲处理槽时启动 - 没有优先级或排序限制。我们使用消息队列(IBM WMQ，因为政治原因)将“开始分析”消息分发到节点。

现在的进展

在遵循各种建议进行大量摆弄之后，结果证明是非工作资源适配器特定的 Cargo-Cult Misinformation™ :)，我 思想 通过为 MDB 定义 EJB 池解决了该问题。这确实解决了并发问题，但不幸的是，似乎没有空闲 MDB 的节点仍会拉取队列中的消息 - 这可能会使一个节点未得到充分利用而另一个节点满载积压。

如果我明白 IBM documentation正确地，这种行为应该可以通过 来控制允许预读 配置选项，但这似乎根本不影响我的结果。

那么，有没有:

一种控制消息消费的 Java EE 标准方法？

一个(工作)IBM WQ 特定的配置选项？

修复它的 JBoss 特定方法？

其他一些我没有想到的智能解决方案？

或者，我可以重新设计架构以使用主题队列，并让每个节点尝试按照 UPDATE Projects SET Status='inprogress' WHERE Id=42 AND Status='inqueue'; 的方式进行操作。 - 但如果我不需要，我宁愿不去那里，主要是因为更改队列所需的更改请求:)

Answer 1

MQ 和 JMS 的设计和优化旨在尽可能快地将消息传递到管道中。每条消息的状态由队列管理器跟踪，但并发要求将要求 QMgr 跟踪彼此相关的消息状态。 MQ 不这样做。

在调整激活规范连接池和事务范围中有一些粒度，但这些旨在影响服务器的动态行为，而不是精确指定它。

跨多个消息管理应用程序状态正是 IBM Integration Broker 等 ESB 产品的设计目的。 MQ 是一种仅查看消息头以执行路由和交付的传输，而 ESB 则查看消息关系和内容。除非 JMS 规范定义了并发管理 API，否则这种由 MQ 负责传输和 ESB 负责处理的职责分工不太可能改变。

不管是用ESB还是JEE代码实现的，你描述的都是Message Dispatcher Pattern来自 Enterprise Integration Patterns书，消息传递世界中权威的架构引用之一。有几种方法可以编写它，具体取决于对仪器的偏好。

代币化

应用程序实例执行 GET在 token 队列和同步点下等待。

收到 token 消息后，应用程序 PUT s 相同的消息回到 token 队列，再次在同步点下。

该应用程序执行 GET等待同步点下的应用程序队列。

收到应用程序消息后，应用程序会对其进行处理，然后执行 COMMIT或 ROLLBACK作为适当的。

应用程序实例在处理应用程序消息之前竞争 token 消息。结果是应用程序消息通常在到达时尽快处理，但在负载下最大并发数等于 token 消息的数量。

通常 token 消息是信息性的，例如包含一个随着每次迭代而递增的计数器，以及可能包含最后一个应用程序的实例信息来写入 token 消息。这提供了一些关于正在发生的事情的诊断见解。在某些情况下，监控应用程序还会监听 token 队列以对该信息进行采样并写入仪表板。在这种情况下，一个额外的 token 消息被添加到队列中以说明监控应用程序的事件。

独立调度员

调度程序应用程序在通告的目标队列上监听消息，并在 ACK 队列上监听确认消息。

计数器将未完成的消息与 {max outstanding message limit} 进行比较在调度程序应用程序的配置中设置。

如果未完成的消息 < 限制，则消息将移动到应用程序的输入队列，并且未完成的消息计数器会增加。

当业务申请GET s 一条消息，它还向调度员的 ACK 发送一条消息队列，同步点下的两个操作。

业务应用问题时COMMIT调度程序收到 ACK 并递减未完成消息计数器。

调度程序应用程序可以请求交付确认消息，但这些消息并不总是与成功处理事务的业务应用程序相关。如果业务应用程序明确地将 ACK 消息与被消费的业务消息放在同一个工作单元中，则结果是坚如磐石的。