[jboss-jira] [JBoss JIRA] (JGRP-2171) New bundler with max_bundle_size for each destination

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2171:
---------------------------
    Description: 
The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent.

This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway).

The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent.

This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s).

We have a main queue, into which the senders write, and a runner thread (same as {{run()}} in TransferQueueBundler), which continually removes messages from the main queue and inserts them into queues for each destination.

So 1 main queue and 1 queue for each destination.

Example:
* {{num_flips}} is 2
* A message for A is sent; it is queued
* Another message for A is sent. Also queued (queue: {{A A}})
* A message to B is sent: {{num_flips}} is now 1, the queue is {{A A B}}
* Another message to A is sent. This resets {{num_flips}} to 2
* 2 messages to C are sent. This causes {{num_flips}} for A and B to be 0, so the batches to A (with 3 msgs) and B (1 msg) are also sent
* No more messages are received, so the batch to C is also sent

The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*. It is maintained for each destination separately (probably in the queue for that destination).

  was:
The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent.

This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway).

The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent.

This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s).

Example:
* {{num_flips}} is 2
* A message for A is sent; it is queued
* Another message for A is sent. Also queued (queue: {{A A}})
* A message to B is sent: {{num_flips}} is now 1, the queue is {{A A B}}
* Another message to A is sent. This resets {{num_flips}} to 2
* 2 messages to C are sent. This causes {{num_flips}} for A to be 0, so the batch to A (with 3 msgs) is sent
* No more messages are received, so the batches to B and C are also sent

The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*.



> New bundler with max_bundle_size for each destination
> -----------------------------------------------------
>
>                 Key: JGRP-2171
>                 URL: https://issues.jboss.org/browse/JGRP-2171
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0.4
>
>
> The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent.
> This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway).
> The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent.
> This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s).
> We have a main queue, into which the senders write, and a runner thread (same as {{run()}} in TransferQueueBundler), which continually removes messages from the main queue and inserts them into queues for each destination.
> So 1 main queue and 1 queue for each destination.
> Example:
> * {{num_flips}} is 2
> * A message for A is sent; it is queued
> * Another message for A is sent. Also queued (queue: {{A A}})
> * A message to B is sent: {{num_flips}} is now 1, the queue is {{A A B}}
> * Another message to A is sent. This resets {{num_flips}} to 2
> * 2 messages to C are sent. This causes {{num_flips}} for A and B to be 0, so the batches to A (with 3 msgs) and B (1 msg) are also sent
> * No more messages are received, so the batch to C is also sent
> The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*. It is maintained for each destination separately (probably in the queue for that destination).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)