JMS队列已满

Question

我的Java EE应用程序发送JMS不断排队，但有时JMS消费者应用程序停止接受JMS。它会导致JMS队列非常大，即使已满，也会崩溃服务器。 我的服务器是JBoss或Websphere。应用程序服务器是否提供了删除“超时”JMS消息的策略？

什么是战略，以处理大量JMS队列？谢谢！

Answer 1

对于任何异步消息，你必须处理“快生产者/消费者慢”的问题。有很多方法可以解决这个问题。

1. 添加消费者。借助WebSphere MQ，您可以根据深度触发队列。一些商店使用它来随着队列深度的增长添加新的消费者实例。随着队列深度开始下降，额外的消费者就会死亡。通过这种方式，消费者可以自动缩放以适应不断变化的负载。其他经纪人通常具有相似的功能。
2. 使队列和底层文件系统真的很大。该方法试图在队列中完全吸收工作负荷峰值。这毕竟是排队设计首先要做的。问题是，它不能很好地扩展，你必须分配磁盘，99％的时间几乎是空的。
3. 过期旧信息。如果信息有过期设置，那么你可以使它们清理。某些JMS代理会自动执行此操作，而在其他可能需要浏览队列的其他JMS代理上则会导致过期的消息被删除。与此相关的问题是，并非所有消息都会失去业务价值并且有资格到期。大多数即时消息（审计日志等）属于此类别。
4. 节制制造商。当队列填满时，没有东西可以给它发新消息。在WebSphere MQ中，生产应用程序接收到一个表明队列已满的返回码。如果应用程序区分致命错误和瞬时错误，它可以停止并重试。

成功实施这些任务的关键是允许您的系统提供应用程序将响应的“软”错误。例如，许多商店在第一次获得QFULL条件时将提高队列的MAXDEPTH参数。如果队列深度超过底层文件系统的大小，则结果是，影响单个队列的“软”错误将导致文件系统填充并影响整个节点。调整系统的好处是，在文件系统填满之前，队列会先撞到MAXDEPTH，然后再调用应用程序或其他进程以某种方式对完整队列作出反应。

但是不管你做些什么，第4个选项以上是强制性的。无论您分配的磁盘数量多少，您部署的客户实例数量或消息过期的速度，您的客户始终都无法跟上消息生产的速度。当发生这种情况时，您的制作人应用程序应该缩回，或者发出警报并停止或执行除挂起或死亡以外的任何操作。异步消息传递只是异步，直到用尽空间来排队消息。之后，你的应用程序是同步的，并且必须优雅地处理这种情况，即使这意味着（优雅地）关闭自己。

Answer 2

当然！

http://download.oracle.com/docs/cd/E17802_01/products/products/jms/javadoc-102a/index.html Message#setJMSExpiration(long)确实如你所愿。