[jbosscache-dev] Re: Non Blocking State Transfer Status (& Integration with JGroups)

[Manik Surtani]

On 7 Jan 2009, at 17:39, Jason T. Greene wrote:

> Bela Ban wrote:
>> Jason T. Greene wrote:
>>> Hi All,
>>>
>>> I wanted to summarize my initial research into NBST. The planned  
>>> design (outlined in the wiki: http://www.jboss.org/community/docs/DOC-10275) 
>>>  only needs to block transactional activity once, at the end of  
>>> the process when sending the tx log. Unfortunately it appears that  
>>> flush and partial flush can not be used for this, since the  
>>> application needs the ability to send state (tx log) during the  
>>> flush.
>> This is possible because FLUSH blocks only *multicast* messages,  
>> not *unicast* messages. This is guaranteed because virtual  
>> synchrony applies only to group messages.
>
> Ah, ok then I can use flush for the final block.

As long as you are talking about a partial flush that just blocks the  
2 members concerned, and not a full flush that blocks the entire  
cluster.  The latter would be a scalability issue.

<SNIP />

>>>
>>> 1. Wait on JGRP-653 (upping its priority), also add requirements  
>>> for a p2p connection.
>> On JGRP-653, I argued against JGRP-653 :-) I don't think it is  
>> necessary, because this can be done by application code, e.g.  
>> similar to what Brian has implemented with farming: the application  
>> chunks up data from an input stream and sends the chunks (governed  
>> by flow control). The receiving side reads the chunks and feeds  
>> them to the recipient (which e.g. reads them from an input stream).
>>
>
> The advantage of supporting this is that you can optimize a number  
> of aspects including the transport, how much of the protocol stack  
> is used, etc when a stream is used. Basically, when someone uses  
> this, they really want a tcp connection.

Well drawn parallel.  This could be a good optimisation, except that  
actually using a TCP socket under the hood will be another  
configuration issue.


--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20090109/7c10c380/attachment.html