[infinispan-dev] To bundle or not to bundle is the question

Radim Vansa rvansa at redhat.com
Mon Nov 11 03:27:57 EST 2013


On 11/08/2013 05:47 PM, Bela Ban wrote:
>
> On 11/8/13 4:15 PM, Radim Vansa wrote:
>> First of all, I think that naming "old", "new" where 3.2.7 new == 3.4.0
>> old sucks. Let's use some more meaningful names.
> Even better: I named the latest bundler "latest" ha ha :-)
>
> These names were never supposed to be exposed to the user, only to
> experts, but +1 on better names... Suggestions ? "default_bundler",
> "default_bundler2" and "transfer_queue_bundler" ? :-)
And DefaultBundler is not the default, currently.

So, to come up with some suggestions (from the 3.2.7 code as there are 
all the ideas):
DefaultBundler -> TimedBundler (bundler_type="timed")
DefaultBundler2 -> LastWaitingBundler ("last_waiting")
TransferQueueBunder -> TimedQueuingBundler ("timed_queuing")
TransferQueueBundler2 -> GreedyQueuingBundler("greedy"/"greedy_queuing")

>
>> Changing the DONT_BUNDLE flag to apply on network communication but
>> rather to stack processing isn't a bad idea, if it helps performance.
>> However, changing the flag meaning to be dependent on the bundler type
>> sounds rather confusing.
> The idea is that when the battle is over, only one bundler will be used,
> so we don't need to make this distinction. However, the "old" bundler
> (which I want to kill at some point) would not perform well when
> bundling all messages.

By the way, I have accepted that 3.4 "old" is 3.2.7 "new", but looking 
into code, I still see that "old" is the one waiting for 
max_bundle_timeout or until there is enough waiting data... Do I miss 
something? Should this "old" bundler really send all messages immediately?

As a last thought for DefaultBundler2 principle (this is the one I find 
most appealing): It seems to me that the thread does not do much work in 
the lock, so the bundle does not grab much messages. The format of batch 
does not specify how many messages will there be in advance, so, instead 
of just adding the message to list (fast), couldn't we keep the 
DataOutputStream and write the message to the stream?

Cheers

Radim
>
>
>> Radim
>>
>> On 11/08/2013 11:47 AM, Bela Ban wrote:
>>> I think I'll ignore the DONT_BUNDLE flag on the sender's side if we have
>>> the right bundler in place. Take a look at [1] and let me know what you
>>> think...
>>>
>>> [1] https://issues.jboss.org/browse/JGRP-1737
>>>
>>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA



More information about the infinispan-dev mailing list