[Xapian-devel] Build problems

[Olly Betts]

On Mon, Feb 12, 2007 at 05:13:20PM +0000, James Aylett wrote:
> On Mon, Feb 12, 2007 at 05:06:31PM +0000, Olly Betts wrote:
> 
> > The idea is that we don't automatically clean up the indexed versions of
> > files which are only read by tests (in order to help speed up the
> > testsuite) but this is sometimes problematic as you've just found.
> > Perhaps we should nuke the cached databases when a test fails.  Or
> > scrap this caching - perhaps it isn't such a time penalty as we
> > originally assumed.  Worth timing at least.
> 
> Nuking on failure might work.

I've just checked, and the current state is that the cached databases
are deleted when a particular backend is selected.  The consequence
is that you shouldn't really encounter this problem, except in
the case where the ".flint" databases are hosed or an older version and
you run apitest with "-b remotetcp" or "-b remote", which uses the
databases in ".flint" (you can do this implicitly with "make check-remote").
If you weren't doing that, I can't see how it failed...

Nuking on failure is problematic, since it prevents you inspecting the
database which can be helpful in working out why a test failed.

Perhaps selecting the remote or remotetcp backend should delete .flint
(or .quartz if flint is disabled), but this seems a bit of a corner case
- I only really see "-b" (or "make check-remote") being useful if you're
trying to debug a failing test, or are working on a particular backend.

> Oh... it doesn't cope with a heavily loaded machine? So it isn't
> waiting long enough for the listening message. It's working for me
> now, and we were under heavy load earlier...

There are timeouts on connection and responses, but those used in the
testsuite are set to 5 minutes so as to not fail just because you're
using a slower machine.  If the load is insane, then they could I guess.

Perhaps ixion actually ran out of VM or processes?

What was the actual error message apitest gave?

Cheers,
    Olly