JMS 2.0: Shared-Durable-Consumer по теме против асинхронного-Consumer в очереди; Ref. Официальная документация по GlassFish 4.0 / руководство по javaee Java EE 7

Ссылка: Официальная документация GlassFish 4.0 / javaee-tutorial Java EE 7

Во-первых, давайте начнем с типа назначения: topic. В соответствии с руководством по GlassFish 4.0, раздел «46.4 Создание высокопроизводительных и масштабируемых приложений JMS»:

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

В подразделе «46.4.2 Использование общих постоянных подписок»:

Клиент SharedDurableSubscriberExample.java показывает, как использовать общие долгосрочные подписки. Он показывает, как общие долговременные подписки сочетают в себе преимущества долговременных подписок (подписка остается активной, когда клиент не активен) с преимуществами общих потребителей (нагрузка сообщения может быть разделена между несколькими клиентами).

Когда мы запускаем этот пример в соответствии с «46.4.2.1 для запуска клиента ShareDurableSubscriberExample и производителя», он дает нам тот же эффект / функциональность, что и предыдущий пример для типа назначения очередь: если мы последуем «46.2.6.2 Для запуска клиентов AsynchConsumer и Producer», баллов 5 и далее - и немного изменим его, используя 2 потребителя окна терминала и 1 окно терминала производителя.

Да, в разделе «45.2.2.2 Стиль сообщений публикации / подписки» упоминается:

JMS API в некоторой степени смягчает это требование, позволяя приложениям создавать устойчивые подписки, которые получают сообщения, отправленные, пока потребители не активны. Долговечные подписки обеспечивают гибкость и надежность очередей, но при этом позволяют клиентам отправлять сообщения многим получателям.

.. и в любом случае в разделе «46.4 Написание высокой производительности и масштабируемости ..» примеры относятся к стилю очереди - одно сообщение для каждого потребителя:

Каждое сообщение, добавленное в подписку на тему, принимается только одним потребителем, аналогично тому, как каждое сообщение, добавленное в очередь, получает только один потребитель.

Каков точный технический ответ: почему в этом примере предполагается использование Shared-Durable-Consumer в теме, о чем упоминается в разделе «Высокопроизводительное и масштабируемое приложение JMS »по сравнению с использованием асинхронного потребителя в очереди?


jms java-ee-7 glassfish-4
person Vishal Panesar    schedule 01.10.2013    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

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

Почему бы не использовать очередь? Ответ довольно прост: если вы используете очередь, только один потребитель сможет обработать такое сообщение.

Для пояснения приведу пример. Допустим, федеральный суд публикует тысячи приговоров каждый день, и у вас есть три различных заявления, которые зависят от него.

Приложение A просто скопируйте предложения в базу данных. Приложение B анализирует предложение и пытается выяснить все отношения между людьми вокруг всех ранее сохраненных предложений. Приложение C анализирует предложение и пытается выяснить все отношения между компаниями по всем ранее сохраненным предложениям.

Вы можете использовать тему для предложений, где будут подписаны приложения A, B и C. Однако легко увидеть, что приложение A может очень быстро обработать сообщение, в то время как приложение B и C может занять некоторое время. Доступное решение могло бы состоять из создания общей подписки для приложения B и другой подписки для приложения C, чтобы несколько потоков могли работать с каждым из них одновременно ...

... Конечно, есть и другие решения, вы можете, например, использовать неразделенную тему (то есть обычную) и публиковать все полученные сообщения на ArrayBlockingQueue, которые через некоторое время будут обрабатываться пулом потоков; однако, приняв такое решение, разработчик будет беспокоиться об обработке очереди.

Надеюсь, это поможет.

person giscard.faria    schedule 06.08.2014

arrow_upward
0
arrow_downward

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

person John Ament    schedule 01.10.2013

arrow_upward
0
arrow_downward

Очередь JMS:

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

Общая подписка JMS:

  1. подписка может иметь ноль для многих потребителей
  2. если сообщения отправлены при отсутствии подписчика (постоянного или нет), сообщение никогда не будет получено.
person user3665417    schedule 01.07.2014