Le 8/10/13 5:19 PM, Kiran Ayyagari a écrit : > On Sat, Aug 10, 2013 at 8:30 PM, Stefan Seelmann > <[email protected]>wrote: > >> 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 [1]. 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
Well, I decided to accept the idea that we may not save all the 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 +1 > Emmanuel, > > 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() ); When we flush the btree, the journal should be emptied. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
