Hi Paul, The issue of ZEBRA updates being slow does not get resolved in zebra 2.0 either. However if you check code in head for zebraop and zebraopserver you will see that the only solution (and working without error) i found is not to update the zebra but to write a new table zebraqueue the biblionumber,server,actiontotake. Another process called zebraqueue_start in z3950 folder runs full time as a deamon and checks this table at set times. Time interval is set at preferences 'zebrawait' in seconds. Currently mine is set to 30 seconds and with around 2000 updates a day zebra can cope with it. On very busy periods changing the system pref to 10 minutes can save the circulation desk but i only had to do that once in 2 months. Regarding zebra updates and zebra crashes we have not been getting any crashes since we stopped using shadow files(contrary to what zebra documentation says). I can say that this method of asynchronous zebra update and no shadow files is working and you should look into implementing it in rel_3 as well before SUN-OP goes live. Cheers, Tümer -----Original Message----- From: koha-devel-bounces+tgarip=neu.edu.tr@nongnu.org [mailto:koha-devel-bounces+tgarip=neu.edu.tr@nongnu.org] On Behalf Of Paul POULAIN Sent: Wednesday, December 06, 2006 1:07 PM To: Koha-devel@nongnu.org Cc: Jérôme Pouchol Subject: [Koha-devel] zebraop commented [for joshua 1st] Hi again, Joshua, you told me yesterday that the commenting of zebraop (*) in dev_week was not a bug, but due to a problem with _zconn in Koha (that looses the connection we don't know why) + it seems that updates are long on large databases. Thus, for adding/updating biblios/items, NPL uses update_items script, running once a day (and thus having a zebra DB uptodate only once a day, which can be considered as a shame, even if not blocking) SAN-OP will go live in january, 3rd, and will do large test (library closed to public, everybody working/testing koha) on dec, 14th, to I thought it could be a good idea to investigate the problem during those tests. Joshua told me that NPL uses zebra 1.x, and SAN-OP will use zebra 2.0, so maybe it could solve the problem. Here is my question : how do we know that the update/insert went wrong ? an internal server error ? an error in the log ? nothing, just being unable to find the added/modified biblio/item ? Did the problem occur once a week or once every hour ? did they notice it occurs more on heavy load or any particular situation ? I'll report here the result of SAN-OP tests. Hoping zebra 2.x will solve it. (*) zebraop is the sub that is called when a biblio/item is added/updated/modified. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel