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? 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? Kind Regards, Stefan [1] https://builds.apache.org/view/A-D/view/Directory/job/dir-mavibot-win/org.apache.directory.mavibot$mavibot/6/testReport/junit/org.apache.directory.mavibot.btree/BTreeFlushTest/testFlushBTree/ On 08/10/2013 04:03 PM, Kiran Ayyagari wrote: > Hi Stefan, > > > On Sat, Aug 10, 2013 at 6:38 PM, Stefan Seelmann > <[email protected]>wrote: > >> Hi, >> >> I have a question regarding the journal. The BTree class creates a >> journal in case the type is PERSISTENT. But if the BTree is managed by >> the record manager then there is no journal. Is that intended, or is it >> not yet implemented? >> >> yes, in managed mode there will be a different file and it contains more > than > one BTree, persist mode is intended to flush the contents of a single tree > to > a single file (i.e., the journal) > > the binary file format is different in both cases > >> Kind Regards, >> Stefan >> > > >
