JGroups concurrent stack and parallelizing messages from the same sender

The concurrent stack has done a great job in parallelizing
delivery of  
messages from different senders, but is there a way to
parallelize  
this from the same sender as well?  Now I know this doesn't
make sense  
in terms of JGroups messages (order needs to be maintained)
but when  
you consider moving up one level of abstraction in JBC, this
causes a  
bottleneck.  Consider, for example:

1. Using sync replication and BR.
2. 3 threads on cache1, working on disjoint data sets (no
contention  
at all, writes can be in parallel).
3. When it comes to replication to the same buddy, the
concurrent  
stack on the receiver will queue the 3 commits.
4. All parallelization achieved in 2. above is wasted since
the  
transactions need to queue anyway.

Is there something we can do with custom message headers,
etc. to  
allow for parallel delivery of these messages?  E.g.,
perhaps using a  
"communication id", which could be a
representation of a global  
transaction?  Bela, Vladimir, any thoughts?

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

I believe this should be possible if you use OOB messages
and custom 
headers. Let's confirm with Bela.

Manik Surtani wrote:
> The concurrent stack has done a great job in
parallelizing delivery of 
> messages from different senders, but is there a way to
parallelize 
> this from the same sender as well?  Now I know this
doesn't make sense 
> in terms of JGroups messages (order needs to be
maintained) but when 
> you consider moving up one level of abstraction in JBC,
this causes a 
> bottleneck.  Consider, for example:
>
> 1. Using sync replication and BR.
> 2. 3 threads on cache1, working on disjoint data sets
(no contention 
> at all, writes can be in parallel).
> 3. When it comes to replication to the same buddy, the
concurrent 
> stack on the receiver will queue the 3 commits.
> 4. All parallelization achieved in 2. above is wasted
since the 
> transactions need to queue anyway.
>
> Is there something we can do with custom message
headers, etc. to 
> allow for parallel delivery of these messages?  E.g.,
perhaps using a 
> "communication id", which could be a
representation of a global 
> transaction?  Bela, Vladimir, any thoughts?
>
> Cheers,
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manikjboss.org
>
>
>
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

I think it will be a big win for us if we can do this - it
is one of  
the biggest bottlenecks with BR in Sync mode.

On 9 May 2008, at 13:13, Vladimir Blagojevic wrote:

> I believe this should be possible if you use OOB
messages and custom  
> headers. Let's confirm with Bela.
>
> Manik Surtani wrote:
>> The concurrent stack has done a great job in
parallelizing delivery  
>> of messages from different senders, but is there a
way to  
>> parallelize this from the same sender as well?  Now
I know this  
>> doesn't make sense in terms of JGroups messages
(order needs to be  
>> maintained) but when you consider moving up one
level of  
>> abstraction in JBC, this causes a bottleneck. 
Consider, for example:
>>
>> 1. Using sync replication and BR.
>> 2. 3 threads on cache1, working on disjoint data
sets (no  
>> contention at all, writes can be in parallel).
>> 3. When it comes to replication to the same buddy,
the concurrent  
>> stack on the receiver will queue the 3 commits.
>> 4. All parallelization achieved in 2. above is
wasted since the  
>> transactions need to queue anyway.
>>
>> Is there something we can do with custom message
headers, etc. to  
>> allow for parallel delivery of these messages? 
E.g., perhaps using  
>> a "communication id", which could be a
representation of a global  
>> transaction?  Bela, Vladimir, any thoughts?
>>
>> Cheers,
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manikjboss.org
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-devlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>

--
Manik Surtani
Lead, JBoss Cache
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Yes, if you mark a message as OOB, then order won't get
preserved, but 
JGroups does guarantee delivery.

I just returned from my vacation and will post a more
detailed message 
on TUE

Vladimir Blagojevic wrote:
> I believe this should be possible if you use OOB
messages and custom 
> headers. Let's confirm with Bela.
>
> Manik Surtani wrote:
>> The concurrent stack has done a great job in
parallelizing delivery 
>> of messages from different senders, but is there a
way to parallelize 
>> this from the same sender as well?  Now I know this
doesn't make 
>> sense in terms of JGroups messages (order needs to
be maintained) but 
>> when you consider moving up one level of
abstraction in JBC, this 
>> causes a bottleneck.  Consider, for example:
>>
>> 1. Using sync replication and BR.
>> 2. 3 threads on cache1, working on disjoint data
sets (no contention 
>> at all, writes can be in parallel).
>> 3. When it comes to replication to the same buddy,
the concurrent 
>> stack on the receiver will queue the 3 commits.
>> 4. All parallelization achieved in 2. above is
wasted since the 
>> transactions need to queue anyway.
>>
>> Is there something we can do with custom message
headers, etc. to 
>> allow for parallel delivery of these messages? 
E.g., perhaps using a 
>> "communication id", which could be a
representation of a global 
>> transaction?  Bela, Vladimir, any thoughts?
>>
>> Cheers,
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> manikjboss.org
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-devlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-devlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

-- 
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat

_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev