JMS топология (Очередь с несколькими потребителями) и сообщение группировки

Question

здесь является упрощенной/схематичной топологией мы создали

[Front server 1 (message producer)] [Front server n (message producer)] 
        |         |   
        |________________ ________________| 
            | |   
         [Messaging Server (HornetQ)] 
            | | 
        ________________| |________________ 
        |         | 
    [Task server 1 (Message Driven Bean)]   [Task server n (MDB)] 

• Каждый узел (сервер) представляет собой автономный (без кластера) сервера приложений JBoss (Jboss -7), включая сообщение.
• Сервер обмена сообщениями развертывает множество очередей JMS.
• Каждый сервер задач развертывает MDB для каждой очереди со многими потребителями.
• Все производители сообщений используют один и тот же входящий адаптер, причем все пользователи сообщений (MDB) имеют одинаковый исходящий. На самом деле все фронт-узлы абсолютно одинаковы (одни и те же AS, одна и та же конфигурация, одни и те же развернутые артефакты), одинаковые для всех узлов сервера.

Теперь вот моя проблема:

приложение является многопользовательским один для данной очереди, некоторые задачи (обработка сообщений) не должны быть обработаны параллельно для данного арендатора, мы создали поэтому message grouping для обработки этого ограничения. Группа сообщения имя арендатора и устанавливается производителем сообщений при отправке сообщения:

message.setStringProperty("JMSXGroupID", tenantName); 

На платформе есть 1000+ арендатор (так 1000+ различные группы сообщений) и для данной очереди 3 потребителя в сервер и 3 сервера задач.

При мониторинге этой очереди на сервере обмена сообщениями мы можем видеть тысячи сообщений в очереди и 9 потребителей. Мы ожидаем, что сообщение будет доставлено с 9 по 9, но на практике количество сообщений о доставке никогда не превысит 1.

В чем проблема? является топологией, подходящей для наших нужд?

Answer 1

Answer from jboss hornetq support forum (КРЕДИТАМ Джастин Bertram):

Я уверен, что вы знаете, очередь имеет первый в первый вышел (т.е. FIFO) семантики. Групповые сообщения в основном действуют как узкое место в очереди , поскольку они обеспечивают обработку последовательных сообщений. Вот простой пример ...

Рассмотрите группы A, B и C, содержащие два сообщения , каждый из которых содержит в общей сложности 6 сообщений в очереди. Также учтите, что они находятся в порядке A, A, B, B, C, C. Теперь рассмотрим 3 разных потребителей , каждый из которых потребляет другую группу. Потребитель для группы A будет получит первое сообщение, обработает его и подтвердит, чтобы он был удален из очереди. Затем он получит второе сообщение, обработает его и подтвердит его, чтобы он был удален из очереди. В течение времени, когда потребитель для группы A занят этими двумя сообщениями , никакие другие сообщения не могут быть использованы из очереди. Только тогда, когда подтверждается второе сообщение , потребитель для группы B фактически получает первое сообщение в группе B. Как только потребитель для группы B подтверждает оба своих сообщения, потребитель для группы C может наконец получать сообщения в своей группе , Это поведение определяется семантикой FIFO очереди. Сообщения в группе B не могут перескакивать сообщения в группе A и потребляться до того, как будут отправлены все сообщения в группе A.То же самое относится и к сообщениям в группе C.

Поскольку все ваши сообщения в группе, я бы никогда не ожидать в доставке счетчик превышает 1.