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