Le 8/10/13 5:19 PM, Kiran Ayyagari a écrit :
> On Sat, Aug 10, 2013 at 8:30 PM, Stefan Seelmann <email@example.com>wrote:Well, I decided to accept the idea that we may not save all the
>> Thanks for the response Kiran.
>> In the meantime I think I found some problems in the BTree journal
>> manager thread and the BTreeFlushTest.
>> 1. On Jenkins Windows Build the BTreeFlushTest failed . The failing
>> assertion checks if the length of the journal file is greater than 0. As
>> the journal manager runs in its own thread it is not guaranteed that the
>> thread run and the journal may not be written. I was able to reproduce
>> it also on Linux when using the MultiThreadedMultiInvoker. I wonder why
>> the journal uses its own thread at all, I thought each modification
>> should immediately written and flushed to the journal?
> yes, agree, not sure what was the reason behind it, Emmanuel may have a
> better answer to this
modifications in case of a crash, but as much as we can. The
modifications are pushed into a blocking queue, and the journal thread
process them as soon as they are some entries in this queue. Doing so
allow the main thread to write fast.
t may bnot be the best solution.
>> 2. I think there is a bug in the BTree's journal manager code. The
>> flushModification() method returns a boolean. It is true when a Addition
>> or a Deletion was added, but then the journal manager thread stops. I
>> guess the boolean value should be inverted?
>> yeap, it is a bug, the return values need to be inverted
> Emmanuel,When we flush the btree, the journal should be emptied.
> I think the journal be deleted every time we flush(by calling flush())
> the data to disk?
> cause at line 245 we have the below assertion, but journal has data
> cause we are not
> truncating it (I ran the testFlushBTree() after inverting the above said
> return values)
> // The journal must be empty
> assertEquals( 0, journal.length() );