JMS队列已满

Question

我的Java应用程序不断地将JMS发送到队列，但有时JMS使用者应用程序会停止接收JMS。它会导致JMS队列非常大甚至是满的，从而使服务器崩溃。我的服务器是JBoss或Websphere。应用服务器是否提供了删除“超时”JMS消息的策略？

处理大型JMS队列的策略是什么？谢谢!

Answer 1

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

1. 添加消费者。使用WebSphere MQ，您可以根据深度触发队列。随着队列深度的增长，一些商店使用它来添加新的消费者实例。然后，随着队列深度开始下降，额外的消费者就会消亡。通过这种方式，用户可以自动扩展以适应不断变化的负载。其他代理一般都有类似的functionality.
2. Make，队列和底层文件系统非常大。此方法尝试完全吸收队列中的工作负载峰值。毕竟，这就是队列最初设计的目的。问题是，它不能很好地扩展，而且您必须分配99%的时间几乎为空的磁盘。
3. 会使旧消息过期。如果消息有过期设置，那么您可以使它们被清除。一些JMS代理将自动执行此操作，而在另一些代理上，您可能需要浏览队列才能删除过期的消息。这样做的问题是，并不是所有的消息都失去了它们的业务价值，并有资格过期。大多数即发即忘消息(审核日志等)落在这个category.
4. Throttle后面的生产者。当队列被填满时，任何东西都不能将新消息放入队列中。然后，在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)完全符合您的要求。