CODEWITHSUNDEEP
jmsmessagingactivemq-artemisjboss-wildfly-11
Garima Natany
Garima Natany

Reputation: 63

How to configure JMS group handling in Wildfly cluster?

I have 2 servers server1 and server2. server1 is the master server and server2 is slave. Both are running in clustered environment.

If 2 messages with same group ID arrives simultaneously on node 1 and node 2 they won't know to which consumer the message should be sent to. Therefore, the message ends up being processed by different consumers and sometimes the message which arrived first gets processed later which is not desirable.

I would like to configure the system so that both nodes know each other that the message should be processed by which consumer.

Solution I tried : Configured the server1 with group handler LOCAL and server2 with REMOTE. Now whenever the message arrives LOCAL group handler identifies that the consumer is on which node and the message is picked accordingly.

This solution is valid until the server1 is running fine. However, if the server1 goes down messages won't be processed anymore.

To fix this I added backup server to messaging subsystem active mq of server1 to server2 and similarly did the same for server2.

/profile=garima/subsystem=messaging-activemq/server=backup:add

And added the same cluster-connection, discovery-group, http-connector, broadcast-group to this backup server but when I tried this solution did not seems to fix the failover condition and messages were not processed on other node.

Please suggest any other approach or how can I configure the scenario where the server with LOCAL group handler stops.

Upvotes: 0

Views: 363

Answers (1)

Justin Bertram
Justin Bertram

Reputation: 35122

The recommended solution for clustered grouping is what you have configured - a backup for the node with the LOCAL grouping-handler. The bottom line here is if there isn't an active node in the cluster with a LOCAL grouping-handler then a decision about what consumer should handle which group simply can't be made. It sounds to me like your backup broker simply isn't working as expected (which is probably a subject for a different question).

Aside from having a backup you might consider eliminating the cluster altogether. Clusters are a way to improve overall message throughput using horizontal scaling. However, message grouping naturally serializes message consumption for each group which then decreases overall message throughput (perhaps severely depending on the use-case). It may be that you don't need the performance scalability of a cluster since you're grouping messages. Have you performed any benchmarking to determine your performance bottlenecks? If so, was clustering the proven solution to these bottlenecks?

Upvotes: 0

Related Questions