[Mulgara-dev] corrupted string-pool?

Andrew Newman andrewfnewman at gmail.com
Fri Feb 23 00:09:20 UTC 2007


On 2/23/07, Paul Gearon <gearon at ieee.org> wrote:
> > I am currently running tests before committing the fix - I believe
> > the bug could be reproduced by inserting a large number of unique
> > literals into the store (sufficient to overflow the caches and force
> > the jvm to buffer IO); followed by a commit(); and then kill -9'ing
> > mulgara immediately the commit returns.
>
> Andrae's suggestion here is an attempt to fill the write-behind buffers,
> committing the data in an inconsistent state (since there is necessary data
> in the write-behind buffer), and then killing the write operation before
> these buffers can reach the disk.
>
> Since we're trying to prevent the IO operations from operating correctly at
> the libc/OS level, it's not a problem that is suitable for running in JUnit!
>
> So we're confident we've found the problem, but consistently reproducing it
> is not
> trivial.  This makes it similarly difficult to properly test that it's
> fixed.
>

This is exactly the kind of thing you do need a test for in order to
get a robust system.  The way you do it is not test everything
(Mulgara, OS write caching, etc) but you do it with an atomic and
integration tests using mocks.  The idea is that you mock out the
complicated behaviour you're trying to reproduce so that your test is
repoducible every time.  Of course, make sure that the mock behaviour
matches the required behavior though.  Much easier and faster to do.

Try EasyMock or JMock and make sure that you have an interface to talk
to and you're set.



More information about the Mulgara-dev mailing list