Appendix 12.2 to the new Koha 3.2 manual suggests running rebuild_zebra.pl as a Cron job every n minutes. However, the zebraqueue_daemon appears to automatically update the biblio database as and when needed. Could someone kindly explain the necessity of the Cron job? We are having a few problems finding sufficient "system level" documentation. Many thanks - Paul --- Archives and Collections (ACS) Society 205, Main Street, Picton, Ontario, K0K 2T0, Canada Canadian Charitable Organization 88721 9921 RR0001
On 3 November 2010 10:31, Paul A. <paul.a@aandc.org> wrote:
Appendix 12.2 to the new Koha 3.2 manual suggests running rebuild_zebra.pl as a Cron job every n minutes. However, the zebraqueue_daemon appears to automatically update the biblio database as and when needed.
Could someone kindly explain the necessity of the Cron job? We are having a few problems finding sufficient "system level" documentation.
Do NOT use the zebraqueue_daemon. The cron job is a far safer option, the daemon is due to be removed (or completely rewritten), it has memory leaks. Chris
On Tue, Nov 2, 2010 at 6:52 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On 3 November 2010 10:31, Paul A. <paul.a@aandc.org> wrote:
Appendix 12.2 to the new Koha 3.2 manual suggests running rebuild_zebra.pl as a Cron job every n minutes. However, the zebraqueue_daemon appears to automatically update the biblio database as and when needed.
Could someone kindly explain the necessity of the Cron job? We are having a few problems finding sufficient "system level" documentation.
Do NOT use the zebraqueue_daemon. The cron job is a far safer option, the daemon is due to be removed (or completely rewritten), it has memory leaks.
I proposed a quick fix that works without adding too much code: assuming the code from rebuild_zebra was right, this approach should make it: http://comments.gmane.org/gmane.education.libraries.koha.devel/4899 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5165 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5166 and I tried to explain the situation, based on the answers I got in the IRC and koha-dev/patches list, and the solution we implemented, here: http://blogs.unc.edu.ar/koha/lang/es/2010/09/06/zebraqueue/ To+
Chris Cormack <chris@...> writes: .. snip ..
Do NOT use the zebraqueue_daemon. The cron job is a far safer option, the daemon is due to be removed (or completely rewritten), it has memory leaks.
Chris
Is this covered by the following bug report? http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2453 If so, then perhaps we can continue to use the daemon if we stay away from large MARC records(?). Using a Cron job to update the index may confuse our volunteers that do data entry (because of the lag, even though we set if for 1 minute). If not, can you please point me to the bug report that covers this problem with zebraqueue so that we can track it? Thanks, Peter.
On Wed, Nov 3, 2010 at 2:22 PM, Peter Huerter <pete.huerter@gmail.com> wrote:
Chris Cormack <chris@...> writes: .. snip ..
Do NOT use the zebraqueue_daemon. The cron job is a far safer option, the daemon is due to be removed (or completely rewritten), it has memory leaks.
Chris
Is this covered by the following bug report?
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2453
If so, then perhaps we can continue to use the daemon if we stay away from large MARC records(?). Using a Cron job to update the index may confuse our volunteers that do data entry (because of the lag, even though we set if for 1 minute).
If not, can you please point me to the bug report that covers this problem with zebraqueue so that we can track it?
If you read the thread I mentioned and google for more info (zebrauqeue+daemon+problem) you will find people saying it is flawed. I asked (without response) if the problem had to do with atomicity on the operations so I could put my hands on: it's a very known and documented pattern... With that in mind, as cron doesn't serialize operations (if an operation takes too much a new process will be launched on deadline) I supposed that creating a new daemon that calls the *trusted* rebuild_zebra routines in a serialized fashion, with configurable intervals of whatever time one wants should have been both harmless (not adding big things that might lead to insolvable or undiscoverable errors) and usefull: non-dev users are very confused about zebraqueue daemon and is not clear what needs to be fixed. I think there are efforts to change the zebra indexing engine in favor of solr, but I think the users need more clear info on the current state of zebra use in koha, and zebraqueue in particular: 1) We should remove zebraqueue_daemon references on the docs, and the svn tree to avoid confusions, and make ir clear that a cron has to be set in any case or 2) We have to create a bug that explains in more detail the problems around zebraqueue_daemon so they can be fixed (I heard about memory leaks this time?), and temporarily do (1) too. or else exactly To+ PD: Yes, I'm a South Park fan.
Hi to all, In the previous month I try to fix the problem of zebraqueue. I find that is too difficult for me. But I find a solution (for my library). Every night I stop the demon zebraqueue and zebreserver for 5 minutes Every sunday I reboot the server. Every month I rebuilt all zebra indexes. Now (on my library) the problem is not present. I have 6000 bib records with 8,000 holdings. My server is linux debian, 1 CPU and 512 MB. Staff work not very much on records and loans (20 transation every day). I find that more RAM I have, less I need to reboot. Probably a more used server needs a reboot every day. The bug to discuss this problem is bug 5165, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5165 There is also an other solution by Tomás Cohen Arazi Bye Zeno Tajoli -- Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci qaunto tra AT con @)
participants (5)
-
Chris Cormack -
Paul A. -
Peter Huerter -
Tomas Cohen Arazi -
Zeno Tajoli