directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: [Mavibot] Journal in BTree and RecordManager
Date Mon, 12 Aug 2013 07:08:44 GMT
On Sun, Aug 11, 2013 at 1:07 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote:

> Le 8/10/13 5:19 PM, Kiran Ayyagari a écrit :
> > On Sat, Aug 10, 2013 at 8:30 PM, Stefan Seelmann <
> mail@stefan-seelmann.de>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.
>
fixed as per MAVIBOT-5

> >
> >> 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
>
these flags are no longer needed, removed them as well as the journal
thread

> > 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.
>
> done, the journal gets truncated using its channel

>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari
http://keydap.com

Mime
View raw message