Mailing List Archive

On Sep 9, 2008, at 11:45 AM, Dan wrote:

> So i have played around a bit and removed all the seg_5.* files and
> things seem to correct itself.
> I'm sure that is screwing up something...

Probably not. If you want to know for sure, look inside the most
recent file named snapshot_XXX.meta. It's a JSON file, so it's human-
readable.

(In fact one rationale behind using JSON was to make troubleshooting
like this possible. It didn't occur to you to open that file, though,
right? Maybe it ought to be named snapshot_XXX.json to make it more
inviting.)

There's a hash for "segments" in that file. If "seg_5" isn't a key,
then any files that start with "seg_5" can be zapped without
consequence.

(Hmm, probably the contents of the snapshot file should be changed to
make it essentially a directory listing plus minimal metadata.)

> How should it act after a failure of a writer?

It should know that a previous write failed and it should clean up any
detritus without you having to worry about it.

> How should i recover from this type of failure?

It shouldn't be your responsibility. Just starting a new indexing
session should be enough.

Please try r3853, it should fix this problem in trunk.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/


_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch

r3857

All test passing and the "clean up" seems to be working great.

Thanks,
-Dan

_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch