| Article: |
Distributed Enterprise Messaging with MantaRay | |
| Subject: | QueueCoordinator | |
| Date: | 2004-12-31 04:51:26 | |
| From: | JMS_newbie | |
|
Ok, that QueueCoordinator was used due to the flip-flop problem and due to the Queue semantics. However that QueueCoordinator seems to me just like a "mini-broker". It can be run on top a producer, consumer or in between, yet it remains a centralized node. Such a concept doesn't seem to justify the promises in the article - "fully distributed", "No Single Point of Failure", "No Single Point of Congestion", ... |
||
Showing messages 1 through 1 of 1.
-
QueueCoordinator
2004-12-31 09:48:32 YLubowich [View]



Getting back to the matter at hand, when a queue coordinator fails the effect on your messaging solution is contained only to the part of the network that failed. Other nodes continue to function and do not suffer any side affects. In order to alleviate local failures like the one I've just mentioned we are now working on dynamic queue coordinators, nodes that are able to take over as coordinators in the event of a failure.
Another issue I feel compelled to mention is the scalability issue, having a centralized broker limits the scalability of your messaging solution. Now you can always add more servers but it will cost you and the broker's salability will not be linear. Two nodes communicating through a centralized broker affect other nodes as well as the broker only has so much CPU/memory/network resources as its disposal. These limitations are nullified by distributing the messaging solution. It is true the same CPU/memory/network resources limitations exits in a distributed solution but their effect are limited to certain portions of the messaging network. In other works two nodes communicating between each other do not necessarily affect other nodes.
Yuval Lubowich