[Koha-bugs] [Bug 12005] Zebra searches sometimes fail silently under Plack

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12005

--- Comment #8 from Chris Cormack <chris at bigballofwax.co.nz> ---
(In reply to Jacek Ablewicz from comment #7)
> (In reply to Chris Cormack from comment #6)
> 
> > This patch changes it so plack works the same way that cgi did.
> 
> At the moment I don't have a persistent install properly set up & suitable
> for any meaningfull testing, but - at least at the 1st glance, this proposed
> patch doesn't look quite right to me: 
> 
> 1) Completely abandoninig Zconn caching would have some measurable impact
> (performance-wise and memory-footprint-wise) in non-persistent
> installations. How significant such an impact may be in the practical
> circumstances is another question - while Koha does not seem to use cached
> Zconn very often, in those rare (?) cases when it does, cached Zconn is
> being used rather extensivelly (eg. when performing authority searches).
> 
It would if it was working, but the caching has never worked. It has never been
doing caching, you make a connection, and use it and then cgi dies and the
connection disappears. In plack you make a connection, you use it, you stop
using it, you asking for a new connection, it tries to give you back the old
one that is dead. Searches break. So while I agree caching would probably be
good, the fact is there is no performance hit from removing it, because we
never had it.

> 2) Removing a code part which used to destroy() previously made zebra
> connection may be not such a good idea IMO. AFAIRC (it's been several months
> since I had a look at that code), previously estabilished Zconn is not being
> atomatically destroyed when the variable which holds it gets udefined, goes
> out of scope, etc. Unless I'm very much mistaken - with this patch applied,
> when running in persistent environment - yes, Koha will indeed make brand
> new zebra connection each time it does perform a search, but the problem is
> that previously made connection[s] would never get destroyed (and they will
> accumulate pretty quicky, eventually leading to the crash when the system
> goes out of available RAM for new zebra processes, free filehandles for
> subsequent connections and so on).

THis is not our experience we have been running it live in production for 6
months, zebra kills the connections without the destroy

-- 
You are receiving this mail because:
You are watching all bug changes.