JMS优先级消息导致低优先级消息不足

我有一个整天都在加载高优先级JMS消息的队列，我想让它们快速离开。队列也会定期加载大量优先级较低的消息。我在繁忙的日子里看到的问题是，队列前面总是有足够多的高优先级消息，在该卷下降之前，不会选择任何低优先级消息。他们通常会排到半夜。该应用程序分布在多个服务器上，但CPU甚至没有呼吸困难，JMS似乎是choak的重点

我的预感是实现某种老化算法，增加队列中已存在很长时间的消息的优先级，但当然，这是中间件应该为我做的。我无法想象JMS提供者（ibmwebspheremq）或应用服务器（tibcobusinessworks）没有某种功能来处理这一问题。所以在我写代码之前，我想我会问，有没有办法让这两种技术中的任何一种帮助我解决这个问题

读取队列的BusinessWorks活动是一个JMS SOAP事件源，但我可以将其转换为JMS队列接收器活动或其他活动

---

关于如何解决这个问题的所有想法都是受欢迎的：-）TIA从您的描述中可以清楚地看出，您希望先处理高优先级的消息。在这种情况下，较低优先级的消息将不得不等待

如果消息长时间处于队列中，MQ不会增加消息的优先级。它如何知道它必须更改消息的属性：）？。您需要开发一个应用程序来实现这一点

我认为基于优先级隔离消息，例如，将高优先级消息放在一个队列中，将低优先级消息放在另一个队列中可能是您可以考虑的一个选项

---

第二种选择是将交付顺序（MSGDLVSQ）更改为FIFO。这使得消息按到达队列的顺序传递给消费者。但请注意，这将忽略消息优先级，这意味着如果优先级较低的消息后面跟着优先级较高的消息，则优先级较高的消息将等待优先级较低的消息发出。

这就像将一只手绑在背后，然后抱怨你不能正常游泳一样。哦！首先，谁的好主意是混合信息。仅仅因为你能做某事并不意味着你应该做

该应用程序分布在多个服务器上，但CPU不是 即使呼吸困难，JMS似乎也是choak点

那么，解决办法很简单。将高优先级消息放入队列“A”（现有队列），将低优先级消息放入新队列“B”。接下来，启动JMS应用程序的另一个实例，从队列“B”中读取消息

此外，JMS可能不是瓶颈。这是应用程序在JMS层拾取需要很长时间（即后端工作）的消息后对消息数据所做的操作

---

最后，您的JMS应用程序有多少个实例在现有队列上运行？如果您只运行一个实例，为什么？如果您有很多CPU容量，那么为什么不运行10个JMS应用程序实例呢。对消息进行一些真正的并行处理。

如果您真的想让消息混合在同一队列中，并首先处理高优先级的消息，但您的消息量太大，有时要到半夜才能处理完所有的消息量，那么您就没有足够的处理应用程序了。MQ是一个并行处理系统，它设计为允许多个应用程序同时放入或从队列中获取。通过同时运行更多的GET应用程序来利用这一点。他们将更快地处理您的高优先级消息，然后再处理低优先级消息。

我认为还值得仔细检查系统的瓶颈是什么。您的站点CPU使用不多。那么，是系统磁盘还是网络绑定？是否考虑增加消费者数量，而不是尝试移动信息优先级？为了跟上信息的产生？