JMS 拓扑(具有多个消费者的队列)和消息组

JMS topology (Queue with multiple consumers) and message groups

这是我们设置的简化/示意拓扑

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

现在这是我的问题:

该应用程序是一个多租户应用程序,对于给定的队列,某些任务(消息处理)不能为给定的租户并行处理,我们设置 message grouping 来处理此约束。消息组为租户名,由消息生产者在发送消息时设置:

message.setStringProperty("JMSXGroupID", tenantName);

在一个平台上,我们有 1000 多个租户(因此有 1000 多个不同的消息组),对于给定的队列,每个服务器有 3 个消费者和 3 个任务服务器。

在消息传递服务器上监视此队列时,我们可以看到队列中有数千条消息和 9 个消费者。我们期望消息按 9 次传递 9 次,但实际上传递中的消息数永远不会超过 1 条。

这里有什么问题?拓扑适合我们的需求吗?

Answer from jboss hornetq support forum(贾斯汀·伯特伦致谢):

As I'm sure you're aware, a queue has first-in-first-out (i.e. FIFO) semantics. Grouped messages basically act like a bottleneck on the queue since they ensure serial message processing. Here's a simple example...

Consider groups A, B, and C which contain two messages each for a total of 6 messages in the queue. Also consider that they are in the order A, A, B, B, C, C. Now consider 3 different consumers each consuming a different group. The consumer for group A will receive the first message, process it, and acknowledge it so that it is removed from the queue. Then it will receive the second message, process it, and acknowledge it so that it is removed from the queue. During the time the consumer for group A is busy with these 2 messages no other messages can be consumed from the queue. Only when the second message is acknowledged can the consumer for group B actually receive the first message in group B. Once the consumer for group B acknowledges both of its messages the consumer for group C can finally receive the messages in its group. This behavior is governed by the FIFO semantics of the queue. The messages in group B can't leap-frog the messages in group A and be consumed before all the messages in group A are consumed. The same goes for the messages in group C.

Since all your messages are in a group I would never expect the in-delivery count to exceed 1.