[Koha-devel] (sort of) Refactoring rebuild_zebra

[Tomas Cohen Arazi]

On Tue, Aug 24, 2010 at 2:29 PM, LAURENT Henri-Damien
<laurenthdl at alinto.com> wrote:
> Le 24/08/2010 19:02, MJ Ray a écrit :
>> Chris Cormack wrote:
>>> On 20 August 2010 09:39, Michael Hafen <mdhafen at tech.washk12.org> wrote:
>>>> I wonder now if we could seperate the two.  So cataloging updated zebra
>>>> immediately, but circulation was queued.
>>>>
>>>> Would that work?
>>>>
>>> Its certainly a possibility, would involve a bit of work, since the
>>> calls are down in module level, not script level, and at that level
>>> often the code doesn't know whether it's being called as a result of
>>> circulation, or a cataloguing change, (or a branch transfer  .. or
>>> whatever else i've forgotten :-))
>>
>> This would be good because I sometimes get asked if Koha's index does
>> "realtime" updating and at the moment the honest answer depends how
>> you define "realtime".  Unlike other systems, librarians can see for
>> themselves the index update process.
>>
>> But I don't know if this limits adoption, as so far no library has
>> offered to pay the co-op to change it.  ;-)
>>
>> I have a slight concern about the rebuild_zebra.pl rewrite: is it
>> perpetuating the daemon/cron competing implementations?  Can
>> we figure out one size that fits all?  Maybe have one daemon
>> running and then different ways for a cron job or librarian
>> interface task to signal (some SIG perhaps?) that it needs to act?
>>
>> Hope that helps,
> If I may contribute my 2 cents :
> I think that rebuild zebra should be separated into two parts :
> - export of biblio
> - indexation
> We could export biblio into a directory, always the same and then
> process that with inotify.
> In fact I think we need a more powerful and robust export tool.
> And since zebraidx is used in rebuild zebra we could use inotify to
> process that and get the logs, to tell whether the indexation went good
> or bad.
> Then it would not be possible to launch more than one zebraidx at once
> and crash the machine.

My proposal of using a daemon that handles the 'sleep task' inside of
it tries to avoid that race condition as it is intended to replace the
cronjob.

To+