11:47 a.m.
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
--
Bela Ban, JGroups lead (http://www.jgroups.org)
4:15 p.m.
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.
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.
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(a)redhat.com>
JBoss DataGrid QA
5:47 p.m.
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" ? :-)
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.
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
>
--
Bela Ban, JGroups lead (http://www.jgroups.org)
9:27 a.m.
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(a)redhat.com>
JBoss DataGrid QA
12:40 p.m.
On 11/11/13 9:27 AM, Radim Vansa wrote:
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")
Thanks for the suggestions I'll change this in 3.5 (branch:
bundler_perf, currently wip)
>> 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?
No, it doesn't. You're right; messages are bundled until the max_size is
exceeded or the max time has elapsed. This should be slower than "new"
or "latest" in 3.4.x, why it isn't is something I'll investigate soon.
Perhaps the tests we're running focus on sync, and sync RPCs always set
the DONT_BUNDLE flag, so bundlig is mostly bypassed. Why "old" is then
not the same as "new" performance wise still escapes me, but hopefully
I'll soon know why.
This investigation will be done in 3.5, it isn't critical to release 3.4.1.
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?
This is something to try out. I updated JGRP-1717 with your suggestion
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
>>>
>>
--
Bela Ban, JGroups lead (http://www.jgroups.org)
8:09 p.m.
On Nov 8, 2013, at 3:15 PM, Radim Vansa <rvansa(a)redhat.com> 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.
On top of that there's an 3.2.7 old as well.
Bela, jgroups protocols are complicated as as they are :-)
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.
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(a)redhat.com>
JBoss DataGrid QA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11:33 a.m.
On 11/8/13 8:09 PM, Mircea Markus wrote:
On Nov 8, 2013, at 3:15 PM, Radim Vansa <rvansa(a)redhat.com> 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.
On top of that there's an 3.2.7 old as well.
Bela, jgroups protocols are complicated as as they are :-)
On purpose; it's called job security for me !! :-)
--
Bela Ban, JGroups lead (http://www.jgroups.org)
8:05 p.m.
On Nov 8, 2013, at 10:47 AM, Bela Ban <bban(a)redhat.com> 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
+1. INFO log it as well perhaps?
--
Bela Ban, JGroups lead (http://www.jgroups.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11:31 a.m.
Hi Mircea,
On 11/8/13 8:05 PM, Mircea Markus wrote:
On Nov 8, 2013, at 10:47 AM, Bela Ban <bban(a)redhat.com> 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
+1. INFO log it as well perhaps?
Yes, I'd log this. But the final solution will be that all bundler
actually send single messages immediately, including the old bundler. I
also want to provide only 1 bundler eventually.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
3876
days inactive
3879
days old
infinispan-dev@lists.jboss.org
8 comments
3 participants
participants (3)
-
Bela Ban -
Mircea Markus -
Radim Vansa