Hi,
Regarding questions 5,6,7:
Q5. issuing a book should not produce 2
lines in zebraqueue so yes we shuld consider it as a minor bug.
Q6. updating in realtime is now possible
but I am not quite sure whether DB crash still occurs so we use zebraqueue with
5 second waits. i even tried with 0 seconds and works fine.
Q7. We have it running as a Windows
service(daemon).No problem. We have also recently ported everything to a
linux server and it runs as a daemon there as well with no
problem
~#perl -e 'print "Hello world\n";
Investigating liblime
recent or less recent commits I have some questions :
==== 1 ====
- the
koha-conf.xml now contains
<listen id="biblioserver"
>unix:__ZEBRA_RUN_DIR__/bibliosocket</listen>
so, no more
address@hidden:port
iirc, unix sockets are much more faster than tcp.
but
:
- does that means we "loose" the z3950 public server in the process ?
-
Is it replaced by the SRU/SRW that is just after ? (ie : can we query
the
SRU/SRW server with PQF queries ?)
==== 2 ====
How to check that the
SRU/SRW works fine ? I tried a yaz-client
@:9998/Biblios and get
:
Connecting...error = System (lower-layer) error: Connection
refused
==== 3 ====
The opensearch & unapi things uses SRU/SRW,
but the port is hardcoded to
9998, were it can be changed in the install
process.
can we consider that as a bug ?
==== 4
====
misc/zebraqueue_start.pl & misc/update_items.pl
afaik :
-
zebraqueue_start was written to update the zebra DB when a biblio
is
updated/added/deleted
- update_items was written to update on a daily
basis all items that
have been updated (to update issuing status of the
item)
now that zebra is quick, a line is added into zebraqueue and
the
"position status" of each item is updated everytime zebraqueue_start is
run.
so do we still need misc/update_items.pl ?
==== 5 ====
It
seems that issuing a book results in 2 lines in zebraque. Isn't this
a bug
?
==== 6 ====
Now that zebra indexes quickly, do we still need
zebraqueue_start ?
couldn't we update in real time ?
(that wouldn't solve
the multiple access problem joshua faced 2 years
ago, when updating the DB
from 2 processes resulted in a DB crash. But
myabe this issue is solved as
well now.)
==== 7 ====
couldn't we transform zebraqueue_start to a
daemon, and not let is as
cronjob ? having to wait for 1mn in the worst case
seems very long to
most librarians (when they add an authority and have to
wait for 1mn to
be able to find it in the biblio)
would that
daemon-ization be a problem for MS-windows servers ?
--
Paul
POULAIN
BibLibre SARL
Expert en Logiciels Libres pour l'info-doc
Tel :
04 91 31 45
19
_______________________________________________
Koha-devel
mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/koha-devel