Jakarta ee WebLogic主题是否保证通过队列传递？

我们正在经历通过队列传递的源和目标之间的消息丢失。源应用程序和目标应用程序都部署在两个不同的WebLogic群集实例中

我们还为消息持久性启用了文件存储，但我们仍然注意到，有些消息并没有从目标队列中使用

提出的解决方案之一是创建一个主题，并在保证消息传递的前提下，通过来自目标应用程序的单个队列进行侦听。我不相信，因为我仍然看到丢失消息的可能性，但如果我们使用一个主题，它将保证配置的使用者至少消费一次消息

---

感谢您对启用保证消息传递的想法。

首先要了解的是，“保证传递”既不是在JMS队列和主题之间选择的标准，也不是队列和主题之间的区别。队列和主题之间还有许多其他标准和区别，比如您会选择队列而不是主题，因为负载平衡的原因，发送到队列的消息将发送到队列的一个使用者，而发送到主题的消息将发送到主题的所有使用者（分布式分区主题除外），这就是在队列的情况下，消息如何在多个队列使用者之间进行负载平衡

现在，我在这里做一个基本的假设，假设你有一个队列Q1，它有3个队列消费者——QC1、QC2和QC3，现在当一条消息被发送到Q1时，这个消息将被发送到消费者QC1、QC2或QC3中的任何一个，它不会被发送到超过1个队列消费者。因此，考虑到这一点，我再次假设，当您说您的消息丢失时，您并不意味着QC1没有收到消息（因为它可能已按预期交付给QC2或QC3）。如果我的假设是错误的，那么这意味着您对JMS队列的理解是不正确的，因此您得到的行为是预期的

现在，有了核心概念，如果现在您得到的行为是预期的，那么使用JMS主题就是正确的解决方案，因为在JMS主题的情况下，消息将传递给所有主题订阅者。因此，假设您有一个JMS主题T1，它有3个主题订阅者-TS1、TS2和TS3，当消息被发送到T1时，该消息将被传递到所有3个主题订阅者

现在，如果您看到您的消息丢失，那么您必须检查这是否仅在某些消息或所有消息中发生，如果是在所有消息中发生，那么您的代码很可能不适合使用/订阅，如果它只发生在一些消息上，那么你需要考虑它是否可能是网络问题

---

更新：根据OP的输入，很明显OP的JMS设置工作正常，迁移到主题没有帮助，现在没有解决方案，这是关于调试问题的，下面是我的想法：

• 您必须从n/w的角度进行调试，确定消息是在JMS生产者到JMS提供者之间丢失，还是在JMS提供者和JMS消费者之间丢失。我猜它在JMS生产者和JMS提供者之间丢失了，因为如果它在JMS提供者和JMS消费者之间丢失了，那么JMS提供者将永远不会得到确认，因此将在其队列中包含消息。您可以检查这些消息是否仍在JMS提供程序队列中，因为您可以使用“队列浏览器”，若消息不在队列中，则表示消息在JMS生产者和JMS提供程序之间丢失
• 这些消息是否有什么不同之处，可能是一些JMS头之类的

---

我以前见过这一点，但老实说：这绝不是JMS主题/队列设置的错误：假设系统正在持续运行（没有崩溃），并且JMS资源也在正常运行（文件存储或数据库未满），那么如果一个消息处理程序正在拾取它未处理的消息，则可以观察到这种行为（它忽略了它们）：

不确定您的消息处理程序是什么样子的，但如果它有一个在交换机案例中按类型“标识”消息或按类型委派消息的概念，则可能是它选择了它不知道的消息。这可能有两个基本原因：

1） 您忘了在（一个！）处理程序中处理丢失的消息类型。主要检查一个看起来很无辜的处理程序：-）

---

2） 您的发送方/接收方代码不匹配，因此“instanceof”由于不一致而失败（我不止一次看到过这种情况）：检查您的代码两端是否使用完全相同的类型

非常感谢您的及时回复。在Q1中接收到的消息被正确地预期为仅由配置队列外的一个使用者使用，在本例中为QC1、QC2或QC3中的一个使用者使用。99%的情况正在发生，我们注意到，很少有一些消息没有被任何消费者消费掉。如果我想给你一些卷的上下文，我们每天处理十万条消息。好的。所以就像我当时说的，这意味着可能存在一些网络问题，您的设置工作正常，导航到主题也没有帮助，这是对的。阅读我的最新答案，了解我的调试想法。