Tibco EMS Сеанс совместного использования объекта Connection

Question

Наше подключение к коду EMS изначально было плохо спроектировано и создало один объект TopicConnection для каждой темы, которую мы прослушали.Таким образом, фактически, всякий раз, когда мы подписываемся на тему, мы создаем новое соединение, новый сеанс и, наконец, новый прослушиватель.

Мы хотели бы переключиться на одну модель соединения.Хотя я могу легко сделать это в нашем коде, разделяя один объект подключения и создавая новый объект сеанса для каждой темы, мы не уверены, вызовет ли это какие-либо проблемы без кода.

Насколько я понимаю, клиентская библиотека Tibco EMS является многопоточной в отношении совместного использования соединения.По сути, соединение - это просто канал, и сеансы могут повторно использовать этот канал потокобезопасным способом.

Верно ли это предположение или есть что-то еще?

Answer 1

.NET EMS API основан на JMS .В JMS объекты Connection и Session указываются как поточно-ориентированные и могут быть повторно использованы в программе.Вы совершенно правы в том, что объект Connection просто представляет сетевой канал к серверу EMS.Руководство пользователя EMS гласит:

Соединение является довольно тяжелым объектом, поэтому большинство клиентов создают соединение один раз и оставляют его открытым до выхода из клиента.Ваше приложение может создавать несколько соединений, если необходимо.

А в отношении сессий:

Сеанс - это однопоточный контекст для создания или потребления сообщений.Вы создаете Производители сообщений или Получатели сообщений, используя объекты Session.

По сути, если вам не нужны очень большие тома и вы сталкиваетесь с ограничениями производительности, совершенно безопасно использовать только одно соединение в вашем приложении.Сеанс контролирует семантику транзакций / подтверждений любых производителей или потребителей, созданных внутри, но снова безопасен для повторного использования.Я бы, вероятно, использовал отдельные сеансы для модулей, существующих в приложении с различными жизненными циклами (представьте себе отдельные модули развертывания на сервере приложений).

В вашей установке сервера EMS будет содержаться каталог примеров с различным кодом (что-то вроде C: \ TIBCO \ \ 5.0 Эмс \ Samples \ * CS 1018 *).Код в csTopicSubscriber.cs показывает, как написать однопоточный потребитель тем.Не существует примера многопоточного потребителя тем, но csMsgConsumerPerf.cs демонстрирует, как это сделать с очередями.

Обязательно очистите все объекты, которые вы создаете, после того, как вы поработаете с ними -например, закройте объект потребителя темы, сеанс и соединение, когда вы закончите.Утечка ручек без их закрытия может привести к непредсказуемому поведению в сочетании с настройками предварительной выборки и отказоустойчивого повторного подключения.

Answer 2

Согласитесь с более ранним ответом: сеанс JMS нельзя разделять между потоками, но соединение может / должно быть.Таким образом, одно соединение на приложение приемлемо (убедитесь, что вы запускаете / закрываете его только один раз - лучше всего до / после создания отдельных потоков).

А затем создайте и используйте один сеанс на поток.Помните, что когда вы закрываете () сеанс, он будет блокироваться до тех пор, пока все обратные вызовы приема действительно не будут возвращены.Поэтому НЕ вызывайте close () из onMessage () обратного вызова.

Answer 3

Я думаю, что да, пока совместное использование в одном приложении (exe, binary). Мы совместно использовали один и тот же объект подключения и использовали его в качестве одиночного кода в нашем коде.