Безопасен ли поток ActiveMQ?
Мы хотели бы запустить наш cms::MessageConsumer а также cms::MessageProducer на разных потоках одного и того же процесса.
Как мы можем сделать это безопасно?
Будет иметь два cms::Connection объекты и два cms::Session Достаточно ли одного объекта для потребителя и производителя, чтобы гарантировать безопасность? Это необходимо?
Существует ли общее состояние между объектами на уровне статической библиотеки, которое могло бы предотвратить использование этого типа?
Решение
Вы должны прочитать спецификацию JMS v1.1, она ясно указывает, какие объекты допустимы для использования в нескольких потоках, а какие нет. А именно, Session, MessageConsumer и MessageProducer считаются небезопасными для совместного использования между потоками. Как правило, мы стараемся сделать их максимально безопасными для потоков, но, безусловно, есть способы, с помощью которых вы можете столкнуться с неприятностями. Как правило, рекомендуется использовать один сеанс в каждом потоке, и в целом рекомендуется использовать сеанс для каждого MessageConsumer / MessageProducer, поскольку сеанс содержит один поток диспетчеризации, что означает, что сеанс со многими потребителями должен совместно использовать свой поток диспетчеризации. для отправки сообщений каждому потребителю, что может снизить задержку в зависимости от сценария.
Другие решения
Я отвечаю на свой вопрос в дополнение к ответу Тима Биша, который, по моему мнению, предоставил необходимую информацию.
От http://activemq.apache.org/cms/cms-api-overview.html
Что такое CMS?
CMS API является следствием C ++ для JMS API в Java, который используется для
отправлять и получать сообщения от клиентов, распределенных по сети или
находится на одной машине. В CMS мы сделали все возможное, чтобы
поддерживать как можно больше паритета с API JMS, расходясь только
когда функция JMS сильно зависела от функций в Java
сам язык программирования. Хотя есть некоторые различия
большинство из них довольно незначительные и по большей части CMS придерживается JMS
спецификация, поэтому, имея твердое представление о том, как работает JMS, следует использовать CMS
это намного проще.
Что спецификация JMS говорит о безопасности потоков?
Скачать спецификацию здесь:
http://download.oracle.com/otndocs/jcp/7195-jms-1.1-fr-spec-oth-JSpec/
2.8 Многопоточность JMS мог требовать, чтобы все его объекты поддерживали одновременное использование. Так как поддержка одновременного доступа обычно
добавляет некоторые накладные расходы и сложность, дизайн JMS ограничивает его
требование одновременного доступа к тем объектам, которые будут
естественно быть разделенным многопоточным клиентом. Остальные
предназначен для доступа к одному логическому потоку управления за один раз.
JMS определяет некоторые конкретные правила, которые ограничивают одновременное использование
Сессии. Поскольку они требуют больше знаний о специфике JMS, чем мы
представили вТаблица 2-2. Объекты JMS, которые поддерживают одновременное использование
- Направление: ДА
- ConnectionFactory: ДА
- Подключение: ДА
- Сессия: НЕТ
- СообщениеПроизводитель: НЕТ
- MessageConsumer: НЕТ
этот момент они будут описаны позже. Здесь мы опишем
обоснование их навязывания.Есть две причины для ограничения одновременного доступа к сеансам.
Во-первых, Sessions — это объект JMS, который поддерживает транзакции. это
очень сложно реализовать транзакции, которые являются многопоточными.
Во-вторых, сеансы поддерживают асинхронное потребление сообщений. это
важно, чтобы JMS не требовал, чтобы клиентский код использовался для асинхронного
потребление сообщений может обрабатывать несколько одновременных
Сообщения. Кроме того, если сеанс был настроен с несколькими,
Для асинхронных потребителей важно, чтобы клиент не был вынужден
обрабатывать случай, когда эти отдельные потребители одновременно
выполнения. Эти ограничения упрощают использование JMS для типичных
клиентов. Более опытные клиенты могут получить параллелизм
желание с помощью нескольких сеансов.
Насколько я знаю со стороны Java, соединение потокобезопасен (и довольно дорог в создании), но сессия а также messageProducer не являются потокобезопасными. Поэтому кажется, что вы должны создать сессию для каждого из ваших потоков.