STREAMING_STATE_TRANSFER in AS 5 sample cfgs
by Manik Surtani
The commented-out STREAMING_STATE_TRANSFER JGroups protocols in AS 5
configs have use_reading_thread set to true. AFAIK, this is deprecated
in JGroups 2.6.7 that ships with AS 5. I'm guessing this is an
oversight?
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
15 years, 1 month
Re: [jboss-cluster-dev] JGroups configurations in JBoss AS 5
by 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(a)jboss.org
15 years, 1 month
Re: [jboss-cluster-dev] JGroups configurations in JBoss AS 5
by Manik Surtani
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.
>
>
> --
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss - a division of Red Hat
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
15 years, 1 month
JGroups configurations in JBoss AS 5
by Manik Surtani
I noticed that the JGroups configs in JBoss AS 5.0.0 and 5.0.1 uses
STATE_TRANSFER as opposed to STREAMING_STATE_TRANSFER. Is there any
reason for this default?
The reason I ask is that non-blocking state transfer in JBoss Cache
3.1.0 requires STREAMING_STATE_TRANSFER to work and I was wondering
whether this may cause other issues elsewhere in the AS.
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
15 years, 1 month