[jboss-jira] [JBoss JIRA] (JGRP-1540) TP: simplified message bundler

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754108#comment-12754108 ] 

Bela Ban commented on JGRP-1540:
--------------------------------

I ran some perf tests with MPerf and UnicastTestRpc (UNICAST3, and batching enabled), results are below:

MPerf (perf is messages/sec/node, in 1000):

||bundler_type||bundler class||run 1|| run 2||run 3|| run 4||run 5||
|old|DefaultBundler|135|166|162|170|171|
|old2|DefaultBundler2|29|22|-|-|-|
|new|TransferQueueBundler|129|150|150|146|147|
|new2|TransferQueueBundler2|137|163|*172*|155|162|

UnicastTestRpc (perf is messages/sec/node, in 1000):

||bundler_type||bundler class||run 1|| run 2||run 3|| run 4||run 5||
|old|DefaultBundler|25|79|93|105|99|
|old2|DefaultBundler2|11|20|22|22|20|
|new|TransferQueueBundler|25|76|115|131|128|
|new2|TransferQueueBundler2|23|49|*175*|107|165|


Bundler type "old2" performed terribly, I think I'm going to remove it now !

Bundler type "new2" won, both for unicast and multicast messages, although "old" was pretty close for multicast messages (and more consistent, too).

Perhaps we can make "new2" the new default, and remove "old2" and "new", leaving only "new2" as default and "old" as fallback...
                
> TP: simplified message bundler
> ------------------------------
>
>                 Key: JGRP-1540
>                 URL: https://issues.jboss.org/browse/JGRP-1540
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.3
>
>
> Instead of maintaining a hashmap (like for the current bundlers), a simple blocking bounded queue of messages would be used. Whenever we've reached M bytes or N milliseconds have elapsed, a consumer thread processes the queue in the following manner:
> * First set the queue to a new queue (volatile assignment), reuse a number of queues
> * Iterate through all messages in the current queue, for each message:
>   ** If the destination is the same as the current destination, write the message to the stream for the current destination
>   ** Else set the current destination to msg.getDest() and create an output  stream (similar to writing a message list)
>     *** Stream the current message to the output stream
>     *** If there was a previous destination, close the associated output stream and send the message list
> Example:
> * We have messages with the following destinations: A, null, null, B, B, null, A, null, null, null
> * First we send a message list consisting of 1 message to A
> * Next we send a message list consisting of 2 messages to the cluster (dest==null)
> * Then we send a batch of 2 messages to B, 1 to the cluster, 1 to A and 3 to the cluster

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira