【发布时间】:2011-09-23 14:00:39
【问题描述】:
当我通过 Servlet 从 JMS 队列接收/使用消息时遇到性能问题。
对 Servlet 的简单请求需要 10 秒来执行 QueueSession 对象的 close 方法(关闭 JMS 资源)。
如果我连续多次使用 Servlet,close 方法需要 20-30 秒。
queueConnection.close() 的并行执行(一次 10 个请求)需要 6-7 分钟。
在同步块中,我将返回 20-30 秒的值来执行 queueConnection.close()。
我感觉 Servlet 线程从池中获取相同的 QueueConnection。
不应该让Servlet从池中获取空闲的连接资源吗?
可以进行以下 JMS 连接工厂的池设置: 初始和最小池大小、最大池大小、池调整大小、空闲超时、最大等待时间。 我尝试了几种池化设置,但没有得到更好的结果。
我想我也必须自己实现池化,以池化我从 OpenMQ 连接池获得的连接,对吗?
我在队列中有超过 40,000 条消息并且消息被参数化(使用消息选择器),这是关闭方法延迟(释放 JMS 资源)的原因吗? 如果我从基于文件的持久性切换到基于 jdbc 的持久性以获得更好的性能,这是否重要?
在下面的答案中建议使用 OpenMQ 的 UMS 组件。 UMS 很有用,但我需要使用消息选择器,我认为 UMS 不支持。
谢谢!
编码:
public class MessageReceiver {
...
public MessageReceiver(){
queueName = "myQueuedestination";
jndiContext = new InitialContext();
queue = (Queue) jndiContext.lookup(queueName);
queueConnectionFactory = (ConnectionFactory) jndiContext
.lookup("myQueueconnectionfactory");
queueConnection = queueConnectionFactory.createConnection();
queueConnection.start();
}
...
public String receive(String KEY, String keyValue) throws Exception {
String returnMessage = null;
String messageSelector = getMessageSelector(KEY, keyValue);
Message m = null;
QueueSession queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
QueueReceiver queueReceiver = queueSession.createReceiver(queue, messageSelector);
m = queueReceiver.receiveNoWait();
if (queueSession != null) {
try {
queueSession.close();
} catch (JMSException e) {
logger.info("There was an error closing the queueSession");
e.printStackTrace();
}
}
queueSession = null;
if (m != null && m instanceof TextMessage) {
returnMessage = ((TextMessage) m).getText();
}
return returnMessage;
}
...
...
}
小服务程序
...
public void init(ServletConfig config) throws ServletException {
...
messageReceiver = new MessageReceiver();
...
}
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{
...
...
synchronized (this)
{
message = messageReceiver.receive(KEY, keyValue);
}
...
...
}
【问题讨论】:
标签: performance glassfish jms message-queue