我们正在经历通过队列传递的源和目标之间的消息丢失。源应用程序和目标应用程序都部署在两个不同的 WebLogic 集群实例中。
我们也为消息持久性启用了文件存储，但我们仍然注意到一些消息没有从目标队列中消费。
建议的解决方案之一是创建一个主题并通过来自目标应用程序的单个队列进行侦听，假设有保证的消息传递。我不相信，因为我仍然看到丢失消息的可能性，但如果我们使用主题，它将保证配置的消费者至少消费一次消息。
感谢您启用有保证的消息传递的想法。
【问题讨论】：
标签： jakarta-ee queue jms weblogic12c jms-topic
首先要了解的是，“保证交付”既不是选择 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 个主题订阅者。
现在，如果您仍然看到您的消息丢失了，那么您必须检查是否只有部分消息或所有消息都发生这种情况，如果是所有消息，那么您的代码很可能不正确消费/订阅，如果它只发生在一些消息上，那么你考虑它是否可能是一些网络问题。
【讨论】：
我以前见过这种情况，但老实说：这绝不是 JMS 主题/队列设置的错：鉴于系统连续运行（没有崩溃）并且 JMS 资源也运行正常（文件存储或数据库未满），那么如果 one 消息处理程序正在挑选它不处理的消息（它会忽略它们），则可以观察到这种行为：
不确定您的消息处理程序的外观如何，但如果它具有在 switch-case 中按类型“识别”消息或按类型委派消息的概念，它可能会选择它不知道的消息。这可能有两个基本原因：
1) 您忘记了（一个！）处理程序来处理丢失的消息类型。主要检查一个看起来很无辜的处理程序:-)。
2) 您的发送方/接收方代码不匹配，因此“instanceof”由于不一致而失败（我见过不止一次）：检查您的代码是否在两端使用完全相同的类型。
【讨论】：