«1. Введение

Компоненты, управляемые сообщениями, также известные как «MDB», обрабатывают сообщения в асинхронном контексте. Мы можем изучить основы MDB в этой статье.

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

Если вы хотите больше узнать об основах параллелизма с использованием Java, вы можете начать здесь.

Чтобы лучше использовать MDB и параллелизм, необходимо принять во внимание некоторые соображения. Важно иметь в виду, что эти соображения должны определяться бизнес-правилами и потребностями нашего приложения.

2. Настройка пула потоков

Настройка пула потоков, вероятно, является основным объектом внимания. Чтобы эффективно использовать параллелизм, мы должны настроить количество экземпляров MDB, доступных для приема сообщений. Когда один экземпляр занят обработкой сообщения, другие экземпляры могут принять следующие.

Поток MessageListener отвечает за выполнение метода onMessage MDB. Этот поток является частью пула потоков MessageListener, что означает, что он объединен в пул и повторно используется снова и снова. Этот пул также имеет конфигурацию, которая позволяет нам установить количество потоков, что может повлиять на производительность:

    установка небольшого размера пула приведет к медленному потреблению сообщений («MDB Throttling») установка очень большого размера пула может снизить производительность или вообще не работать.

В Wildfly мы можем установить это значение, обратившись к консоли управления. Возможность JMS не включена в автономном профиле по умолчанию; нам нужно запустить сервер, используя полный профиль.

Обычно при локальной установке доступ к нему осуществляется через http://127.0.0.1:9990/console/index.html. После этого нам нужно зайти в Configuration/Subsystems/Messaging/Server, выбрать наш сервер и нажать «View».

Выберите вкладку «Атрибуты», нажмите «Изменить» и измените значение «Максимальный размер пула потоков». Значение по умолчанию — 30.

3. Настройка максимального количества сеансов

Еще одно настраиваемое свойство, о котором следует помнить, — максимальное количество сеансов. Это определяет параллелизм для конкретного порта прослушивателя. Обычно это значение по умолчанию равно 1, но его увеличение может повысить масштабируемость и доступность приложения MDB.

Мы можем настроить его либо с помощью аннотаций, либо с помощью дескрипторов .xml. Через аннотации мы используем @ActivationConfigProperty: 

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(
        propertyName=”maxSession”, propertyValue=”50”
    )
})

Если выбран метод конфигурации с дескрипторами .xml, мы можем настроить maxSession следующим образом: 

<activation-config>
    <activation-config-property>
        <activation-config-property-name>maxSession</activation-config-property-name>
        <activation-config-property-value>50</activation-config-property-value>
    </activation-config-property>
</activation-config>

4. Среда развертывания

Когда у нас есть требование для обеспечения высокой доступности следует рассмотреть возможность развертывания MDB на кластере серверов приложений. Таким образом, он может выполняться на любом из серверов в кластере, и многие серверы приложений могут вызывать его одновременно, что также улучшает масштабируемость.

В этом конкретном случае у нас есть важный выбор:

    сделать все серверы в кластере доступными для получения сообщений, что позволяет использовать всю его вычислительную мощность, или обеспечить последовательную обработку сообщений с помощью разрешить их одновременное получение только одному серверу

Если мы используем корпоративную шину, хорошей практикой является развертывание MDB на том же сервере или кластере, что и член шины, для оптимизации производительности обмена сообщениями.

5. Модель сообщения и типы сообщений

Хотя это не так очевидно, как простое задание другого значения для пула, модель сообщения и тип сообщения могут повлиять на одно из лучших преимуществ использования параллелизма: производительность.

Например, при выборе XML для типа сообщения размер сообщения может повлиять на время, затрачиваемое на его обработку. Это важное соображение, особенно если приложение обрабатывает большое количество сообщений.

Что касается модели сообщений, если приложению необходимо отправить одно и то же сообщение большому количеству потребителей, модель публикации-подписки может быть правильным выбором. Это уменьшит накладные расходы на обработку сообщений, обеспечив лучшую производительность.

Чтобы потреблять из темы по модели публикации-подписки, мы можем использовать аннотации: 

@ActivationConfigProperty(
  propertyName = "destinationType", 
  propertyValue = "javax.jms.Topic")

«

<activation-config>
    <activation-config-property>
        <activation-config-property-name>destinationType</activation-config-property-name>
        <activation-config-property-value>javax.jms.Topic</activation-config-property-value>
    </activation-config-property>
</activation-config>

«Опять же, мы также можем настроить эти значения в дескрипторе развертывания .xml:

Если отправка одного и того же сообщения многим потребителям не является обязательным требованием, будет достаточно обычной модели PTP (точка-точка). 

@ActivationConfigProperty(
  propertyName = "destinationType", 
  propertyValue = "javax.jms.Queue")

Для потребления из очереди мы устанавливаем аннотацию как: 

<activation-config>
    <activation-config-property>
        <activation-config-property-name>destinationType</activation-config-property-name>
        <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
    </activation-config-property>
</activation-config>

Если мы используем дескриптор развертывания .xml, мы можем установить его:

6. Заключение

Как много Ученые-компьютерщики и ИТ-писатели уже заявили, что скорость процессоров больше не растет быстрыми темпами. Чтобы наши программы работали быстрее, нам нужно работать с большим количеством процессоров и ядер, доступных сегодня.