Page History

...

• Primary: primary owner of the Queue/Exchange.
• Backup: becomes primary if primary fails. <- comments - I would expect that you would want to be able to configure the number of backups used in a cluster per resource 1,2,3. Don't know if there is any benifit beyond 3) ->
• Proxy: forwards to primary. <- assume by default, everyone that is not primary is a proxy in a cluster ->

This application is partitioned by assigning groups of queues/exchanges to primary brokers. The same broker can be primary for one exchange, backup for another, proxy for another etc.

...

Proxy exchanges have the same name as their remote counterpart so they they can be used as if they were the remote counterpart.

Comment - To maintain QoS I assume the ansync reply as defined by the transport SIG would not be issued from the proxy to the publisher until successfully enqueued by the Primary.

Consume from proxy queue

Proxy queue consumes, gets and acknowledges messages from remote queue on behalf of its clients. It must not acknowledge any message until it has received acknolwedgement from its client. It should use flow control to avoid consuming messages unless it has a client ready to consume them.

TODO: draw out the scenarios for avoiding "stuck message syndrome" where a proxy queue consumes a message but then has nobody to pass it on to.

Comment - To maintain QoS I assume the dequeue from Primary would not be issued by the proxy until successfully receiveing the reply sequence from the consumer.

Bind local queue to proxy Bind local queue to proxy exchange

Proxy exchange creates private queue on remote broker and binds to remote exchange with identical binding arguments. Proxy exchange consumes from private remote queue and enqueues messages on the local queue.

...

Unlike queues and exchanges, sessions cannot be proxied. In the event of failure sessions are tranferred to another broker. After a failure a client can re-establish the session on any cluster broker.

<- comment – how does the client know which node in the cluster to reconnect to, and how is the list of nodes in the cluster published to the client-- assume it use the system exchange ->

A session is active from the time a client connects up to the failure of the connection, the broker or the client. If the broker sees a connection failure, it marks the session disconnnected.

...

TODO: Failover merges the primary's resource set with the backup. Do we also need to allow resource sets to be split so a primary broker can offload part of its resource set on another broker? - I would say yes, also on failure another backup need to be identified as one node got lost. also all back-ups on the node that was primary also need to be replicated to another node.

The cluster map.

The cluster map lists

...

All other traffic between brokers will use AMQP. The majority of traffic can be done using the proxy techniques described above. Other communication is via system exchange and queuescommunication is via system exchange and queues.

comment — if a high number of backups is configured it might be more effient to run AMQP over AIS for this distribution, however this can be seen as an optimization and done later.

TODO: is there a need for any other protocols?

...

For example: brokers could be arranged in a ring with each broker being the backup fro the preceeding one. To add a new broker you choose a point in the ring to insert it and the adjacent brokers adjust their responsibilities accordingly. Implies we can transfer "backupship" as well as ownership.

comment – believe in any scheme we need to be able to transfer "backupship" as well as "ownership" as when a node in the cluster fails, both may be present on that node.

Broker Failover

Transient resources and transient messages survive failover to an active backup, but not failure of both primary and backup.

...

Logs and persistence.

Use GFS or shared storage offered by the platfrom to share storage between brokers. Two types of storage to consider:

...