Women in Technology

Hear us Roar



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", ...
Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • QueueCoordinator
    2004-12-31 09:48:32  YLubowich [View]

    You are partially right, the Queue Coordinator can be thought of as a mini centralized broker in the sense that the machine hosting the coordinator can fail. However as opposed to "normal" brokers, the effect of a failure is limited. When a centralized broker crashes or hangs you entire messaging solution fails. MantaRay on the other hand aims to distribute the MOM; notions that have been found in the hardware domain (switches, routers etc.) for a long time.
    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