...@users.sf.net]
Sent: den 2 oktober 2014 16:37
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] Re: #952 immsv: sync data Mbcsv Check
pointing can be optimized
Yes that makes sense.
But continuos small ccbs of this kind is not really a realistic test of immsv.
Real CCB
...@users.sf.net]
Sent: den 2 oktober 2014 16:37
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] Re: #952 immsv: sync data Mbcsv Check
pointing can be optimized
Yes that makes sense.
But continuos small ccbs of this kind is not really a realistic test of immsv.
Real CCB
Yes that makes sense.
But continuos small ccbs of this kind is not really a realistic test of immsv.
Real CCB usage is typically a burst of small changes or in some cases one large
CCB.
Very rarely is there a continuous stream of new CCBs generated over a long time.
in fact you could argue that i
In one of my test case where I was creating contentious objected creation on
bother Active & Standby then triggered fail-over and observed very large
data (size:92808 see below ) in FinilizeSync message , if I Stop Object
creation on both node and give some delay of 5 minits , and then do f
Ccb outcome (commit/abort) is synced.
This should not be very litle data compared with all the rest.
It is used to redundantly verify the outcome of CCBs.
The nightmre scenario for me would be some state missmatch within the IMMNDs
that resultet
in a CCB getting derailed (and aborted) at one IMMN
