So, we applied Dobrica's patch on bug 13815, and this solved pretty much
all of our problems. We'll be doing some more testing, but it turns out
it was very much encoding related. (I guess Robin's catalog is in
english language and didn't have this issue.)
I realize there's one thing i didn't mention in my message: we are
testing plack for the staff interface, i am much more confident for the
opac indeed. (So much so that we didn't even test the opac! I guess we
should...)
Another thing i didn't mention in my original email is that we found bad
.po files can cause plack to crash: if your translated string doesn't
have the same number of %s as the original, this will result in a badly
formated template, which will crash plack. (e.g. an if tag that is never
closed.) Somehow this doesn't induce a crash when plack is not enabled.
I had always thought that if the %s count for a string was wrong, the
translation engine would leave the original string. It seems it's more
complicated than this.
Anyway, we'll be doing more tests and i'll keep you posted about our
findings!
Le 20/04/2015 00:12, Robin Sheat a écrit :
Gaetan Boisson schreef op do 26-03-2015 om 16:17 [+0100]:
we have been talking about plack quite a lot in the last hackfest, and
i
must say i am not that comfortable with the technical aspects and
hardly
understand what the issues are, but...
I apparently missed this message when it was first posted.
Anyway, we have a plack system in production. I'd link you to it, but
it's closed and so it'll do you no good.
It is really speedy though. In this case it's needed because this
library sends out monthly newsletters to its members who then all
descend on the OPAC en masse, which in the pre-plack days would make it
OOM or at least just give up responding. However with plack, it serves
the responses fast enough that it can handle the high load with a lot
more success.
The script I use to convert a package install to use plack is here:
http://git.catalyst.net.nz/gw?p=koha-plack.git
One of these days I'll probably make a branch of Koha that includes
plack support by default in the packages, or make a package that
provides the appropriate diverts to switch everything on that machine to
plack, I haven't decided which way to go yet.
We do have a few minor issues, but nothing as severe as what you're
talking about.
The main problem is that user separation makes memory allocation tricky
as you need to pre-allocate per koha instance, which is a bit much. At
the same time, we don't want to risk giving the process read access to
every koha-conf.xml as that's dangerous. We do have a solution for this
(it's weird, but it'll do), I just haven't had a chance to tie it in.
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
--
Gaetan Boisson
Chef de projet bibliothécaire
BibLibre
06 52 42 51 29
108 avenue Breteuil 13006 Marseille
gaetan.bois...@biblibre.com
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
