@lzap: да, см. раздел 2.8 спецификации по многопоточности.
я возникли проблемы с пониманием 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.3Weblogic подключается к IBM MQ 7.0 (проблема также появляется с 6.0) для JMSВышеуказанная логика выполняется одним потоком на внутреннем сервере. Было бы просто сохранить некоторые объекты (QueueConnection
, QueueSession
, QueueSender
) в памяти, так как нет параллелизма.Мои вопросыКакие типы объектов могут быть общими для нескольких сообщений? (конечно, мы включили бы восстановление после ошибок, восстановление этих общих объектов)Каковы лучшие практики для повышения производительности?