Why is the z3950 daemon needed? What steps are needed to get rid of it? Is it possible to run one per server instead of one per koha installation? Thanks for any answers. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
MJ Ray wrote:
Why is the z3950 daemon needed?
The initial author of the daemon is steve tonnessen. How it works ? * the daemon looks at the z3950queue table. If he finds a row that hasn't been spawned into z3950results, he spawns it. * the daemon looks at the z3950results table. If he finds a row that has not been "forked", he forks. In the new process, he calls the z3950server, and when he get answers, he saves them in the marc_breeding table (this being my contribution) there is an annoying bug in the spawn process : if the server name has spaces, he is divided in X differents server calls, which all fails.
What steps are needed to get rid of it?
imho, it's mandatory, as z3950 may be very slow, so we need to have asynchronous requests.
Is it possible to run one per server instead of one per koha installation?
The daemon use koha.conf file to find DB, user & password. I don't know how to change this behaviour & have more than 1 .conf file. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Thanks for the explanation, Paul. On 2003-09-29 08:32:40 +0100 paul POULAIN <paul.poulain@free.fr> wrote:
What steps are needed to get rid of it? imho, it's mandatory, as z3950 may be very slow, so we need to have asynchronous requests.
How slow? Slower than the normal apache maximum runtime?
Is it possible to run one per server instead of one per koha installation? The daemon use koha.conf file to find DB, user & password. I don't know how to change this behaviour & have more than 1 .conf file.
Is there an obvious reason not to use sockets and give the daemon its own database config? -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
MJ Ray wrote:
Thanks for the explanation, Paul.
On 2003-09-29 08:32:40 +0100 paul POULAIN <paul.poulain@free.fr> wrote:
What steps are needed to get rid of it?
imho, it's mandatory, as z3950 may be very slow, so we need to have asynchronous requests.
How slow? Slower than the normal apache maximum runtime?
Possible. but that's not the problem : if enters 4 z3950, we shouldn't wait for 4 synchronous answers before sending him something. It would need 4-8 seconds. the daemon solution gives a "blank screen" to the user, saying "Koha is working", then answers are shown as soon as they arrive. It's more a human patience problem than a Apache one :-)
Is it possible to run one per server instead of one per koha installation?
The daemon use koha.conf file to find DB, user & password. I don't know how to change this behaviour & have more than 1 .conf file.
Is there an obvious reason not to use sockets and give the daemon its own database config?
I don't know. Probably not. Ask steve Tonnesen ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2003-09-30 15:22:05 +0100 paul POULAIN <paul.poulain@free.fr> wrote:
but that's not the problem : if enters 4 z3950, we shouldn't wait for 4 synchronous answers before sending him something. It would need 4-8 seconds. the daemon solution gives a "blank screen" to the user, saying "Koha is working", then answers are shown as soon as they arrive.
This would not require a daemon. Send a "koha is working" first of all and a redirect to the results page. The results page should not return anything (not even headers) until all results are in. Requests should still not be done synchronously if possible, to ensure that we can abort before the maximum runtime. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
MJ Ray wrote:
On 2003-09-30 15:22:05 +0100 paul POULAIN <paul.poulain@free.fr> wrote:
but that's not the problem : if enters 4 z3950, we shouldn't wait for 4 synchronous answers before sending him something. It would need 4-8 seconds. the daemon solution gives a "blank screen" to the user, saying "Koha is working", then answers are shown as soon as they arrive.
This would not require a daemon. Send a "koha is working" first of all and a redirect to the results page. The results page should not return anything (not even headers) until all results are in.
that's where we have not the same idea : I think users are happy to see that the query progresses.
Requests should still not be done synchronously if possible, to ensure that we can abort before the maximum runtime.
and how to do this with a web platform without a daemon (or cron job or anything else) ? If i don't mind, the web platform is : IP stack of server recieve a IP packet Apache get the packet. Apache sees it's a CGI call Apache forks a process/thread to compute the answer The process/thread output the results The process/thread dies Apache sends the results when the process/thread is dead Job ended. I don't see how to have an asynchronous task here. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2003-10-21 09:39:24 +0100 paul POULAIN <paul.poulain@free.fr> wrote:
that's where we have not the same idea : I think users are happy to see that the query progresses.
Is seeing "Please wait" bugzilla-style really worse than "Still ?? requests to go" that we have now? Admins are very unhappy at having to run new daemons and I think this will limit koha uptake. Z39.50 is a good feature of koha, but its current implementation seems tricky. I suspect the daemon may hit ulimits too?
Apache forks a process/thread to compute the answer The process/thread output the results The process/thread dies Apache sends the results when the process/thread is dead
I think this line is wrong. Apache sends the results as soon as it can, without waiting for process to exit.
Job ended.
I don't see how to have an asynchronous task here.
I was speaking of the results being gathered asynchronously within the process, not the request being asynchronous within the whole system. This is so that we can abort when time runs out. I don't think that is difficult to do. Perhaps we could even use alarm signals to avoid having to write asynchronous Z3950 code. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
participants (3)
-
MJ Ray -
MJ Ray -
paul POULAIN