http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12005 --- Comment #8 from Chris Cormack <chris@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.