On Tue, Aug 24, 2010 at 2:29 PM, LAURENT Henri-Damien <[email protected]> wrote: > Le 24/08/2010 19:02, MJ Ray a écrit : >> Chris Cormack wrote: >>> On 20 August 2010 09:39, Michael Hafen <[email protected]> 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+ _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
