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?
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?
On 08/10/2013 04:03 PM, Kiran Ayyagari wrote:
> Hi Stefan,
> On Sat, Aug 10, 2013 at 6:38 PM, Stefan Seelmann <email@example.com>wrote:
>> 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
> one BTree, persist mode is intended to flush the contents of a single tree
> a single file (i.e., the journal)
> the binary file format is different in both cases
>> Kind Regards,