-
1. Re: Remote Clustered Hornetq JMS Provider - Weblogic Consumer
jbertram Sep 28, 2017 8:30 PM (in response to karthicktm)I believe that the JNP implementation supports multiple URLs. However, even if it doesn't you should still be able to consume all the messages in a queue in the cluster just by connecting to one node assuming that you've configured a non-zero redistribution-delay.
Also, the connection factory you client looks up via JNDI should be using the default round-robin connection load-balancing policy so when you use the same connection factory to create multiple connections those connections should be distributed across the nodes in the cluster in a round-robin fashion.
-
2. Re: Remote Clustered Hornetq JMS Provider - Weblogic Consumer
karthicktm Sep 28, 2017 11:34 PM (in response to jbertram)Hi Justin,
Thanks for the reply.
I have set redistribution-delay to zero. I will make some delay there.
I have one more query here. My weblogic consumer connects to the first instance of hornetq even though i have put comma separated with other instance of hornetq in Jndi URL. So, now what happening is, when the consumers are down ( weblogic goes down ), the messages coming to hornetq get distributed again across the instances and when the weblogic comes back to normal, only those messages in first instance of hornetq getting consumed and the messages in other instances of hornetq goes pending.
How i can configure this scenario?
Thanks
-
3. Re: Remote Clustered Hornetq JMS Provider - Weblogic Consumer
jbertram Sep 29, 2017 9:09 AM (in response to karthicktm)When all the messages of a queue in a cluster node are consumed but consumers are still attached then messages in that same queue from other nodes in the cluster which have no consumers will be redistributed to the node where the consumers are attached.
One thing to think about...If your load is so small that you're starving consumers then you may not need a cluster at all. A single HornetQ node can handle millions of messages per second so it's quite possible you could use a single node and avoid all this extra configuration, testing, and management. Have you actually conducted performance benchmarks which conclusively indicated that you needed more than one node?