[jboss-cluster-dev] JGroups configurations in JBoss AS 5

[Manik Surtani]

On 24 Feb 2009, at 18:37, Jason T. Greene wrote:

> Manik Surtani wrote:
>> On 24 Feb 2009, at 16:41, Bela Ban wrote:
>>>
>>>
>>> Manik Surtani wrote:
>>>> Yes, but it relies on an open stream between the 2 instances.   
>>>> State is written without a flush, and then a marker is placed on  
>>>> the stream asking the state requester to start a partial flush so  
>>>> that the final tx log can be written to the stream as well.
>>>
>>> IIRC the marker is on the TX log, so you can use either streaming  
>>> or regular state transfer. Whether or not we use streaming state  
>>> transfer should be hidden from the caller of Channel.getState()
>> Nope.  Regular state tfr will wait till the entire state is ready  
>> and then transfer the byte buffer.  This is no good for NBST since,  
>> with NBST, here is what happens:
>> 1.  Joiner (Cache B) joins, requests state from Cache A
>> 2.  A generates and starts streaming state to B
>> 3.  When state is transferred, A starts streaming tx log
>> 4.  When remaining tx log is small, A puts a marker on the stream
>> 5.  B sees this marker and requests a flush
>> 6.  Once flush is detected by A, write remaining tx log and *this*  
>> ends the state transfer process.  7.  B releases the flush
>> So when using regular state tfr, B will not see the marker placed  
>> by A in step 4, since the stream is flushed to a byte buffer and  
>> transferred in 6.  A will never get to step 6 until B starts a  
>> flush in step 5.  And for this to happen, state needs to stream  
>> across constantly and not wait for the state generation process to  
>> complete.
>
> Writing all of your state to a big byte array is a bad idea anyway ;)

Yes.  I can see how this can easily lead to OOMs.

Cheers
Manik

--
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/jboss-cluster-dev/attachments/20090224/b2606185/attachment.html