我将Spring 3.2.8与JDK 6和Websphere MQ 7.5.0.5一起使用。在我的应用程序中，我通过ThreadPool使用jmsTemplate进行一些jms调用。首先，我面临的条件是＆＃34;当前队列深度＆＃34;当我点击jms电话时，计数会增加。我通过ThreadPool跟踪我正在启动的所有对象，并中断或取消所有线程/未来对象。所以这个＆＃34;当前队列深度＆＃34;数控制。
现在问题是＆＃34;打开输入计数＆＃34;值几乎增加到我发送的请求数。当我停止服务器时，此计数变为0。
在所有这些情况下，我能够发送请求并获得响应，直到80和我的ThreadPool大小为30.在达到80的请求计数后，我一直收到未来对象拒绝的错误，并且无法接收响应。实际上，对于剩余的呼叫，会收到空响应。
请建议。
答案 0 :(得分：2)
我在我的应用程序中使用队列，并且已经应用了关联ID的过滤器。我在上面阅读了更多内容，并在我们拨打jmsTemplate.receiveSelected (queue, filter)时发现，这对性能产生了严重影响。删除此过滤器后，线程连接问题已解决。但是现在过滤对我来说仍然是一个问题。
现在我将以不同的方式应用过滤器，但有一些应用程序的限制但不使用receiveSelected而是使用jmsTemplate.receive。
全部 - 我发现这是一个解决方案，并希望在此发布。
我的一位同事帮助纠正了这个问题，这是非常有帮助的。我们在调试后观察到如果cacheConsumer为true则基于
的组合queue + message-selector + session
消费者被Spring缓存。甚至调用close()方法也没有做任何事情;基本上是空方法并导致线程被挂起/卡住。
在将cacheConsumer设置为false后，我将我的代码恢复为原始的jmsTemplate.receiveSelected (destination, messageSelector)，现在当我点击100次请求时，线程数在多次迭代测试期间仅增加到5到10之间。
所以 - 需要仔细使用这个属性。
希望这会有所帮助!!
答案 1 :(得分：0)
首先，我面临“当前队列深度”计数增加的条件 我打了jms电话。我通过ThreadPool跟踪了我发起的所有对象 并中断或取消所有线程/未来对象。
我不知道你在说什么，但你不应该使用/监控应用程序中的“当前队列深度”值。糟糕，糟糕的设计。只有MQ监控工具才能使用它。
现在问题是“开放输入计数”值几乎增加到了数字 我发送的请求。当我停止服务器时，此计数变为0。
编程错误。你正在“一次又一次地打开一个队列，然后发一条消息”。你把一些代码放到CLOSE队列或者更好的方法，重新开放队列!!!!!!!