[jbosscache-dev] JGroups concurrent stack and parallelizing messages from the same sender

[Manik Surtani]

On 13 May 2008, at 11:39, Bela Ban wrote:

>
>
> 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)
>
> Not necessarily. Sometimes you just want reliable delivery but don't  
> care about ordering. To do that and still provide once-only  
> delivery, mark your message as OOB (out-of-band):
>
> Message msg=new Message();
> msg.setFlag(Message.OOB);  // msg.clearFlag(Message.OOB) clears this  
> flag again
>
> OR
>
> use one of the RpcDispatcher.callRemoteMethod(s) methods with the  
> OOB parameter set to true.

Yes, I'm already using OOB for commit messages as a workaround for  
deadlocks in certain situations.

>> 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.
>
> You can use the above mechanism. However, you have to make sure that  
> any thread
>
>   * uses synchronous replication
>   * the commits are synchronous as well
>
> This won't work for asynchronous replication, but I don't think it  
> is needed here anyway right ?

It is most critical in sync replication, correct, but why should it  
not work with the async case as well?  I'm guessing misaligned packets?

--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org