【发布时间】:2011-07-25 03:35:32
【问题描述】:
我在从性能角度理解 JMS 时遇到了一些麻烦。我们的应用程序中有这个非常简单的代码:
QueueConnection connection = null;
QueueSession session = null;
QueueSender sender = null;
TextMessage msg = null;
try {
// The JNDIHelper uses InitialContext to look up things
QueueConnectionFactory qcf = JNDIHelper.lookupFactory();
Queue destQueue = JNDIHelper.lookupQueue();
// These objects are created for every message, which is quite slow
connection = qcf.createQueueConnection();
session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
sender = session.createSender(destQueue);
// This is the actual message
msg = session.createTextMessage(xmlMsg);
sender.setTimeToLive(0);
sender.send(msg);
}
finally {
// Close all objects again
JMSUtilities.safeClose(sender);
JMSUtilities.safeClose(session);
JMSUtilities.safeClose(connection);
}
代码是正确的,但可能上述一些人工制品可以重复用于多条消息。这些是我们的配置:
- 我们使用 Oracle Weblogic 10.3.3
- Weblogic 连接到用于 JMS 的 IBM MQ 7.0(6.0 也出现问题)
- 上述逻辑由后端服务器上的单个线程执行。将一些对象(
QueueConnection、QueueSession、QueueSender)保留在内存中会很简单,因为不涉及并发。
我的问题
- 哪些类型的对象可以在多条消息之间共享? (当然我们会包括错误恢复、恢复那些共享对象)
- 提高性能的最佳做法是什么?
【问题讨论】:
-
我对您的 finally 块中的 JMSUtilities.safeClose() 方法非常感兴趣。它们是 IBM MQ 7.0 的一部分吗? (我没有使用)或其他什么?通过搜索找不到太多。实现我的第一次发送到 JMS,希望避免一个丑陋的 finally 块与大量的空检查。
-
@user640118:它们是本地实用工具链的一部分。本质上,他们只是执行空检查并关闭对象,而不是火箭科学。
标签: java jms weblogic message-queue