Hi Stefan, Thanks for the response.
>>* Another commit Cn+1 comes - this marks Cn as "external" and itself >>gets dropped > > Cn is not marked as external though, but yes, Cn+1 is dropped. > Ah!, I see now how that's working. >>* The listener can consume all events till Cn, but Cn+1 and future >>ones don't get to listener > >>Is this expected? > > Good point. I think this might have been known but not really acknowledged > as a bug. I guess the reason being that in reality, for a large n, > consuming the queue while no new change is coming in sounds unrealistic. > Yeah, I realized why this was never a big deal/remained undiscovered. > But agreed, this is a bug and we should fix it. > Actually, I'm not too sure as long as we concretely document the behavior and potentially have a sample abstract commit-creator/listener which does the job well (may be similar to the hack I used) > A fix could perhaps be to keep track of the Cn+1 (the overflow change) > more explicitly - and check for that also when polling from the queue. > I really don't want to change a behavior unless I can guarantee that nothing un-expected happen. Observation being so core, I wonder how easily/confidently can we give that guarantee. >>I was under the assumption that on arrival of Cn+1, >>Cn gets dropped and Cn+1 is put in. Cn+1 is also marked external. > > No, only in case Cn was external and Cn+1 is also external does Cn get > dropped and Cn+1 added instead. > Ack. Thanks, Vikas
