Producer Flow Control with Clusters - Question

[bruceas]

I have a (hopefully) simple question about producer flow control and clusters. (I've read the relevant sections in the manual, but this part still confuses me).

Suppose the following situation:

- Address full policy set to block

- Round robin load balancing

- three nodes (A, B, C), all part of the same cluster

- Each node has both a producer and a consumer

- Each of the three producers are sending messages at a constant rate to the queue EXAMPLE_QUEUE, defined on each node

- Each of the three consumers are receiving messages from the queue EXAMPLE_QUEUE

- The consumers on nodes B & C are relatively fast; the consumer on node A is very slow

My understanding is that messages sent by the producers will be forwarded to the consumers/nodes in round-robin fashion, e.g. A->B->C->A->B->C, etc.

Suppose that EXAMPLE_QUEUE on node A becomes full (e.g. max-size-value is reached), but the EXAMPLE_QUEUEs on nodes B and C are (relatively) empty.

Will this cause all of the producers to become blocked, even though the EXAMPLE_QUEUE on nodes B and C are relatively empty?

(My understanding is that the round-robin forwarding will be blocked by node A, which in turn will block/deadlock *all* of the producers).

Is there any way to prevent or work around these types of blocks (e.g. for all three producers to keep sending data to the queue on nodes B and C, even though the queue on node A is full)

Thanks in advance...

[clebert.suconic]

The message is always sent locally before it's transferred to other nodes. it's not going to other nodes directly, hence if you set it to block it will wait you consume messages before it unblocks on that specific node.

[bruceas]

Thanks... but I don't fully understand...

Suppose there was no producer on node A (but it still had the slow consumer). What happens with respect to the producers on nodes B and C when the queue on node A becomes full? Wouldn't they also (eventually) become blocked as well?

[clebert.suconic]

I believe edge cases like these will probably let messages to get in. (As long as the other nodes are still consuming messages)

[bruceas]

Maybe if I rephrase the question...

Are "other nodes" considered producers with respect to blocking?

For example, consider the following example taken directly from the HornetQ User Guide ("Server-Side Mesage Load Balancing").

"

If we define a cluster connection on node A, then as ordered messages arrive on node A instead of all of them going

into the local

OrderQueue

instance, they are distributed in a round-robin fashion between all the nodes of the cluster.

The messages are forwarded from the receiving node to other nodes of the cluster. This is all done on the server side,

the client maintains a single connection to node A.

For example, messages arriving on node A might be distributed in the following order between the nodes: B, D, C,

A, B, D, C, A, B, D. The exact order depends on the order the nodes started up, but the algorithm used is round robin.

"

Supposed that the OrderQueue on node C is full (that is, it has reached max-size-bytes, and the address-full-policy is BLOCK).

Consider the following statement:

"... messages arriving on node A might be distributed in the following order between the nodes: B, D, C, A, B, D, C, A, B"

What happens with respect to the round-robin algorithm when node C is full? Is the message forwarding from node A blocked in this case?

e.g. How can messages be forwared in the order B,D,C,A,B,D,C,A,B when node C is "full" and set to block?

(Wouldn't the message forwarding stop at node C, e.g. B,D,C -->and then everything gets blocked until space on C is freed up?)

Thanks

[clebert.suconic]

Yes... the other nodes are considered producers, There will be a bridge between the nodes and the bride will be a producer. If you stop consuming on a node the bridge between these nodes will block and the whole thing will just block.

If you're not sure you can have a consumer at all times, you should probably use paging.

[bruceas]

Thank you very much! This answers my question!