From kohanews at gmail.com  Sat Dec  1 05:13:30 2018
From: kohanews at gmail.com (kohanews)
Date: Fri, 30 Nov 2018 20:13:30 -0800
Subject: [Koha-devel] Koha Community Newsletter: November 2018
Message-ID: <02cd16b8-17a1-eb7e-5ad6-a8604136edce@gmail.com>

The Koha Community Newsletter for November 2018 is here:
https://koha-community.org/koha-community-newsletter-november-2018/

Many thanks to the folks who submitted articles and news to this month's 
newsletter.

Please feel free to email me with any corrections or suggestions.

-- 
Chad Roseburg
Editor, Koha Community Newsletter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181130/afd06faf/attachment.html>

From mtompset at hotmail.com  Tue Dec  4 03:59:03 2018
From: mtompset at hotmail.com (Mark Tompsett)
Date: Tue, 4 Dec 2018 02:59:03 +0000
Subject: [Koha-devel] HTML filtering issue
Message-ID: <BYAPR11MB2967D28EADD4749657049371C6AF0@BYAPR11MB2967.namprd11.prod.outlook.com>

Greetings,

Find a record, change/add something like:
---- BEGIN SAMPLE ---
this
<hr>

is
<hr>

a
<hr>

test
---- END SAMPLE ---
To 500$a for that record and save it.

Now go view ?Title notes? in the OPAC for this record.
Ugly HTML mess.

line 717 of opac-detail.tt
Not sure how to fix. Any ideas?

GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181204/44b24217/attachment.html>

From oleonard at myacpl.org  Tue Dec  4 13:57:25 2018
From: oleonard at myacpl.org (Owen Leonard)
Date: Tue, 4 Dec 2018 07:57:25 -0500
Subject: [Koha-devel] HTML filtering issue
In-Reply-To: <BYAPR11MB2967D28EADD4749657049371C6AF0@BYAPR11MB2967.namprd11.prod.outlook.com>
References: <BYAPR11MB2967D28EADD4749657049371C6AF0@BYAPR11MB2967.namprd11.prod.outlook.com>
Message-ID: <CAO4qe2OA9WCdFjgEhqfUwiSNM9HQa7zPMU+gBbTLFQOfij7Y1w@mail.gmail.com>

> this
> <hr>
> To 500$a for that record and save it.
>
> Now go view ?Title notes? in the OPAC for this record.
> Ugly HTML mess.

This is how I would expect it to work. MARC isn't intended to have
HTML markup in it.

 -- Owen

-- 
Web Developer
Athens County Public Libraries
https://www.myacpl.org

From dcook at prosentient.com.au  Wed Dec  5 02:12:09 2018
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 5 Dec 2018 12:12:09 +1100
Subject: [Koha-devel] HTML filtering issue
In-Reply-To: <CAO4qe2OA9WCdFjgEhqfUwiSNM9HQa7zPMU+gBbTLFQOfij7Y1w@mail.gmail.com>
References: <BYAPR11MB2967D28EADD4749657049371C6AF0@BYAPR11MB2967.namprd11.prod.outlook.com>
	<CAO4qe2OA9WCdFjgEhqfUwiSNM9HQa7zPMU+gBbTLFQOfij7Y1w@mail.gmail.com>
Message-ID: <02b201d48c37$8bee09b0$a3ca1d10$@prosentient.com.au>

That's what I used to think as well. 

Then I learned about "887 - Non-MARC Information Field"  https://www.loc.gov/marc/bibliographic/bd887.html. 

Not that we'd be showing 887 on the OPAC, but... MARC just has to be difficult.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Owen Leonard
Sent: Tuesday, 4 December 2018 11:57 PM
To: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] HTML filtering issue

> this
> <hr>
> To 500$a for that record and save it.
>
> Now go view ?Title notes? in the OPAC for this record.
> Ugly HTML mess.

This is how I would expect it to work. MARC isn't intended to have HTML markup in it.

 -- Owen

--
Web Developer
Athens County Public Libraries
https://www.myacpl.org
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/



From mtompset at hotmail.com  Wed Dec  5 05:30:49 2018
From: mtompset at hotmail.com (Mark Tompsett)
Date: Wed, 5 Dec 2018 04:30:49 +0000
Subject: [Koha-devel] HTML filtering issue
In-Reply-To: <02b201d48c37$8bee09b0$a3ca1d10$@prosentient.com.au>
References: <BYAPR11MB2967D28EADD4749657049371C6AF0@BYAPR11MB2967.namprd11.prod.outlook.com><CAO4qe2OA9WCdFjgEhqfUwiSNM9HQa7zPMU+gBbTLFQOfij7Y1w@mail.gmail.com>
	<02b201d48c37$8bee09b0$a3ca1d10$@prosentient.com.au>
Message-ID: <BYAPR11MB2967AD38680B07748C4390A1C6A80@BYAPR11MB2967.namprd11.prod.outlook.com>

Greetings,

Oleonard wrote:
> MARC isn't intended to have HTML markup in it.

Dcook replied:
> That's what I used to think as well.
>
> Then I learned about "887 - Non-MARC Information Field"
>  https://www.loc.gov/marc/bibliographic/bd887.html.


Could you (Owen and David) then peruse and review bug 21947?
I don't think I tweaked anything that looked like it could have come from 
887.

GPML,
Mark Tompsett 


From Holger.Meissner at hs-gesundheit.de  Wed Dec  5 10:20:09 2018
From: Holger.Meissner at hs-gesundheit.de (Holger Meissner)
Date: Wed, 5 Dec 2018 09:20:09 +0000
Subject: [Koha-devel] Autorenewals renewing an item then sending a renew
 failure email the next day
In-Reply-To: <015301d48a9c$2b960410$82c20c30$@prosentient.com.au>
References: <00c401d47d68$f2c27cd0$d8477670$@prosentient.com.au>
	<ed0ac08a1d1540c3aed3d8f1127ab66d@nExchange2.hsg.intra>
	<000201d486b0$b967f130$2c37d390$@prosentient.com.au>
	<eb6f156e113143b38699672e2e9c3251@nExchange2.hsg.intra>
	<005501d4883c$3a534ce0$aef9e6a0$@prosentient.com.au>
	<15BB8384-4CC4-4768-AFC7-2715A19001AD@su.se>
	<015301d48a9c$2b960410$82c20c30$@prosentient.com.au>
Message-ID: <df3ebbd5e0734950875988c9a7952f4d@nExchange2.hsg.intra>

I seem to have trouble sending emails, let's try plain text this time. I'm sorry if you receive multiple messages.

Well, I contributed the original thing (Bug 11577) but not the AUTO_RENEWALS notification. I assumed that this new notification was optional and disabled by default. Seems that I was wrong there? Probably cait disabled it locally for us, before we even noticed :)

So just syspref the notification for now? What do you people at ByWater and PTFS Europe say? Did 15705 get pushed by accident, still missing a way to disable notification?

It really should be optional. I?m still not convinced it's illogical - if libraries for some reason want to autorenew verbosely. We don't, but I suppose you?d just have to be very careful with the wording of the e-mail. Especially in a big library with title level holds. I can see it being quite annoying in that use case.

Here's what I'm worried about: Rearranging the error precedence in CanBookBeRenewed wouldn't just affect autorenewals, it would affect all issues and how they are displayed in opac and in staff client.

> If you want to notify patrons when someone places a hold on their loan so that they can decide
> to return it out of courtesy, I?d recommend making adding a different feature for that

I think that's actually a great idea! Equal notification for all holds. Yet, it would be confusing if a patron is notified, then logs into opac and can't see the holds they were notified about. Also, I want to see holds in staff client as soon as they are placed. If you don't, then making the error precedence configurable might be a solution.

Another wild idea, if really necessary make CanBookBeReturned return multiple reasons. Maybe using a bit field, to speed up the extra work as much as possible and easily check for any combination of renewal errors. Or maybe just using new ?too soon and on hold? and ?auto too soon and on hold? errors.

Regards,
Holger


Von: David Cook <dcook at prosentient.com.au> 
Gesendet: Montag, 3. Dezember 2018 01:07
An: 'Andreas Hedstr?m Mace' <andreas.hedstrom.mace at su.se>; Holger Meissner <Holger.Meissner at hs-gesundheit.de>; koha-devel at lists.koha-community.org
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi Andreas,

Can someone post a patch for your local fix? It?s my intention to write a patch at some point, but I?ve had a number of other tasks occupying my attention lately (as well as being off sick). I?d be happy to test an existing patch though. 

As the original author of the function, I?d like to hear more from Holger. It looks like Hochschule f?r Gesundheit sponsored the patch as well? So I?m guessing that the current way it functions must be working for them. I?d hate to break functionality that is working for someone. I?m thinking adding configurability of the ordering of steps might be the best bet. What do you think, Holger? 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

From: Andreas Hedstr?m Mace [mailto:andreas.hedstrom.mace at su.se] 
Sent: Friday, 30 November 2018 7:54 PM
To: David Cook <mailto:dcook at prosentient.com.au>; 'Holger Meissner' <mailto:Holger.Meissner at hs-gesundheit.de>; mailto:koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi all!

In general, I agree with David?s conclusions. We had plenty of confusion from patrons when first implementing autorenewals, and have now fixed it locally.

Since we are a fairly large academic library, for popular material there will ususally be several copies of a book, where each of these can fill a placed hold. So sending out an email that it won?t be autorenewed far ahead of the due date to all the patrons doesn?t make much sense, since the hold might be cancelled or filled by another copy by the time it is actually tries to renew (as set by ?no renewal before? in the circulation rules).

Making these steps configurable could be a viable way forward I believe.

Best regards,
Andreas

________________________________________

Andreas Hedstr?m Mace
Systems Librarian
Stockholm University Library
Stockholm University
106 91 Stockholm?
Tel: +46 (0) 8-16 49 17?
su.se/english/library/

________________________________________




Fr?n: <mailto:koha-devel-bounces at lists.koha-community.org> p? uppdrag av David Cook <mailto:dcook at prosentient.com.au>
Datum: fredag 30 november 2018 00:36
Till: 'Holger Meissner' <mailto:Holger.Meissner at hs-gesundheit.de>, "mailto:koha-devel at lists.koha-community.org" <mailto:koha-devel at lists.koha-community.org>
?mne: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Thanks for your feedback, Holger. 
?
Do you currently use autorenewals? I think you might be misunderstanding how it works?
?
The precedence of ?on hold > too many > too soon? is illogical for autorenewal in my mind. When the autorenewal daily cronjob runs, it will only send email alerts for ?too many? and ?on hold?. The most common outcome of the script should be ?too soon? as it?s during the normal loan period before the due date, so it really should be the first check. If it?s not ?too soon?, then you try to process a renewal. The next step would be checking if you have any renewals left. If not, then it?s ?too many?. If you do have renewals left, then you move to the next check, which would be checking for holds. The logical precedence would be ?too soon > too many > on hold?. 
?
?A patron might decide to return that book earlier if they know someone else is waiting instead of just knowing that it won?t be renewed anymore?. That seems to be a corruption/bleeding of scope for an autorenewal script. If you want to notify patrons when someone places a hold on their loan so that they can decide to return it out of courtesy, I?d recommend making adding a different feature for that (and probably integrate it with recalls which could optionally shorten the due date of the on loan item so the patron has to return it earlier for the person who put the hold on it ? recalls is a common feature in other established ILS/LMS systems). 
?
?And knowing that the book won?t be renewed anymore is more useful information than just knowing that it?s too early right now?. Firstly, they don?t currently know that it?s too early, as email notifications don?t go out for ?too soon?. Secondly, I have patrons returning their books when they get the ?can?t autorenew because there is a hold?, because they think that their book has been recalled even though Koha thinks they actually have several weeks left, because their loan was in fact successfully autorenewed the day before they got the ?on hold? email notification. 
?
At this point, librarians are getting annoyed at Koha for misleading patrons, and I?m advising librarians to not use the autorenewal function as a result. 
?
My options are as follows:
1) Continue warning people that this feature doesn?t work as they expect, which doesn?t look good for Koha
2) Patch the script via the Koha community workflow, which is ideal for developers and librarians
3) Patch the script locally, which is far from ideal, but will make librarians happy
?
I?ve been extremely busy, but it is my intention to submit a patch for this. If there is enough disagreement about the order of steps, perhaps it would be best to make the order of steps configurable. It wouldn?t be a difficult thing to do. 
?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
?
Office: 02 9212 0899
Direct: 02 8005 0595
?
From: mailto:koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Holger Meissner
Sent: Friday, 30 November 2018 1:29 AM
To: mailto:koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
?
Thanks for the explanation, David.
?
> Yes, I would like to get the ?too soon? error message instead of the ?on reserve? error message if both apply.
?
I?d rather not. If patrons only know it?s too early they will expect a renewal. Which won?t happen, because of the hold we already know about. Why not tell them right away?
I would agree if holds were canceled most of the time, but in my estimate they aren?t.
?
> Koha shouldn?t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item?s status is on loan.
?
How would you implement something like that? The autorenew cronjob can?t do nothing. It has to try and renew everything every time it runs.
?
> In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1
> 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen
> until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can?t renew because of a hold. 
?
I believe they are treated equally, i.e. nothing prevents Person A from manually trying to renew again on September 2. And in that case they will see the hold.
?
> Currently, people are getting emails telling them they can?t autorenew their book on September 2 2018 because someone has
> placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.
?
I?m probably missing something but I don?t see what?s illogical or misleading about it.
?
I think on hold > too many > too early is good precedence, because of the information they give. A patron might decide to return that book earlier if they know someone else is waiting, instead of just knowing that it won?t be renewed anymore. And knowing that the book won?t be renewed anymore is more useful information than just knowing that it?s too early right now, even if all three apply at the same time.
?
Regards,
Holger
?
Von: David Cook <mailto:dcook at prosentient.com.au> 
Gesendet: Mittwoch, 28. November 2018 01:24
An: Holger Meissner <mailto:Holger.Meissner at hs-gesundheit.de>; mailto:koha-devel at lists.koha-community.org
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
?
Hi Holger,
?
Nope, I don?t want to change autorenewal being stopped when a hold is placed. 
?
Yes, I would like to get the ?too soon? error message instead of the ?on reserve? error message if both apply. 
?
Here?s my reasoning:
?
1) Book A is due on September 1 2018
2) Book A is autorenewed until September 15 2018
3) Person B places a hold on Book A
4) Koha shouldn?t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item?s status is on loan. 
?
In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can?t renew because of a hold. 
?
Currently, people are getting emails telling them they can?t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical. 
?
It shouldn?t be trying to autorenew because it?s ?too soon?. Only when it?s otherwise renewable should we be checking for holds. 
?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
?
Office: 02 9212 0899
Direct: 02 8005 0595
?
From: Holger Meissner [mailto:Holger.Meissner at hs-gesundheit.de] 
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <mailto:dcook at prosentient.com.au>; mailto:koha-devel at lists.koha-community.org
Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
?
Hi David,
?
could you expand on this? It?s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?
?
Or would you like to get the ?too soon? error message instead of the ?on reserve? error message if both apply? Or a new message informing you about both?
?
What?s the benefit of checking whether it?s too early first?
?
Regards,
Holger
?
?
Von: mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> Im Auftrag von David Cook
Gesendet: Freitag, 16. November 2018 05:58
An: mailto:koha-devel at lists.koha-community.org
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
?
Hi all,
?
I?ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can?t renew the item. (Someone must?ve put a hold on the item between the two cronjob runs.)
?
It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written. 
?
The first check it makes is for holds and if it finds a hold it returns an error. 
?
However, if you?re using autorenewals, you should first check to see if it?s too early to even bother renewing. 
?
I?m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn?t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.
?
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
?
Office: 02 9212 0899
Direct: 02 8005 0595
?

From jonathan.druart at bugs.koha-community.org  Wed Dec  5 20:20:35 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 5 Dec 2018 16:20:35 -0300
Subject: [Koha-devel] Cache::Memory must be removed (21955)
Message-ID: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>

Hi devs,

I am still recovering from my holidays and I think I caught a quite big fish.

After an interesting track game I will explain why I am suggesting to
remove Cache::Memory that is currently used as fallback for the L2
cache.

What I tried to fix:
Jenkins is complaining about selenium tests (regressions.t) failing on
18.05, it is a succession of events and bugs that were not linked at
first glance.

Here are the different steps I went though:
- On bug 21426 we noticed that USE_MEMCACHED was not taken into
account. If set to "no" the default memcached config was defined in
the koha-config.xml file anyway
- A new regression selenium test was added on bug 21777 to catch the
presence of an audio alert on the circulation page
- Investigating the failing tests I noticed that koha-testing-docker
was not setting the memcached config on the 18.05 branches (I guess
the image has not been rebuilt yet)
search_utf8.t output "Warning: script running in daemon mode, without
recommended caching system (memcached)."
- I also find that [% Koha.Preference('AudioAlerts') %] did not return
the value set by the tests, but the value that the DB has before the
tests were launched
=> It is a cache issue!
- ...but only when memcached is not set...
- Reading Koha::Cache->new we can notice that Cache::Memory is used
for the L2 cache when memcached is not defined in the config

And so we have the problem: If a value is set in the cache by a Plack
worker, it will not be available from another one, as the L2 cache is
not shared (!)

To recreate easily the problem you can:
- remove the memcached config
- edit intranet-bottom.inc and add
===[% Koha.Preference('AudioAlerts') %]===
- restart plack
- Modify the value of AudioAlerts (using the UI)
- Reload the page (reload several times if the value is still correct,
it will depend on which worker will serve the request)

Solution:
I am considering removing Cache::Memory unless somebody else has a better idea
Bug 21955 - Cache::Memory should not be used as L2 cache

Note that it should not affect a lot of people as everybody is
supposed to have memcached configured and working correctly!

Cheers,
Jonathan

From admin at mhe-krg.org  Wed Dec  5 21:27:07 2018
From: admin at mhe-krg.org (MHE IT admin)
Date: Wed, 5 Dec 2018 23:27:07 +0300
Subject: [Koha-devel] Upgrade to Koha 18
Message-ID: <CA+O2VWVac8xPGHbRrDGFWaPCSAGO44p4pwu7qS9ovTddcX8e9g@mail.gmail.com>

Hi,

We have just upgraded our Koha 17 to Koha 18. We have one issue, new
records added but they are not found in the search. We tried to find a
solution but we could not find any reported issue on this.

Our library
http://library.koyauniversity.org:8080/

Please let us know if there anything we can do to solve this problem.

Dilan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181205/b0c4c05d/attachment.html>

From chrisc at catalyst.net.nz  Wed Dec  5 21:30:25 2018
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Thu, 6 Dec 2018 09:30:25 +1300
Subject: [Koha-devel] Upgrade to Koha 18
In-Reply-To: <CA+O2VWVac8xPGHbRrDGFWaPCSAGO44p4pwu7qS9ovTddcX8e9g@mail.gmail.com>
References: <CA+O2VWVac8xPGHbRrDGFWaPCSAGO44p4pwu7qS9ovTddcX8e9g@mail.gmail.com>
Message-ID: <0b154cd2-830d-2c3d-492d-990f9247216b@catalyst.net.nz>

Hi Dilan

There is 17.05, and 17.11 and 18.05 and 18.11.
So you will need to tell us which actual version of Koha you are running.

(There is no Koha 17 or Koha 18)

Chris

On 6/12/18 9:27 AM, MHE IT admin wrote:
> Hi,?
> 
> We have just upgraded our Koha 17 to Koha 18. We have one issue, new
> records added but they are not found in the search. We tried to find a
> solution but we could not find any reported issue on this.?
> 
> Our library?
> http://library.koyauniversity.org:8080/
> 
> Please let us know if there anything we can do to solve this problem.?
> 
> Dilan
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

From admin at mhe-krg.org  Wed Dec  5 21:37:35 2018
From: admin at mhe-krg.org (MHE IT admin)
Date: Wed, 5 Dec 2018 23:37:35 +0300
Subject: [Koha-devel] Upgrade to Koha 18
In-Reply-To: <0b154cd2-830d-2c3d-492d-990f9247216b@catalyst.net.nz>
References: <CA+O2VWVac8xPGHbRrDGFWaPCSAGO44p4pwu7qS9ovTddcX8e9g@mail.gmail.com>
	<0b154cd2-830d-2c3d-492d-990f9247216b@catalyst.net.nz>
Message-ID: <CA+O2VWU+ApiNDqdBDC1R3B39pW-KKVb_2WNpcO_k90HM56Yg_A@mail.gmail.com>

Sorry to miss that. This is the information I go from the admin

Koha version: 18.05.05.000
OS version ('uname -a'): Linux koyauniversity.org 4.9.0-8-amd64 #1 SMP
Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64
Perl interpreter: /usr/bin/perl
Perl version: 5.024001
Perl @INC: /usr/share/koha/lib
/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.24.1
/usr/local/share/perl/5.24.1
/usr/lib/x86_64-linux-gnu/perl5/5.24
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.24
/usr/share/perl/5.24
/usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base
MySQL version: mysql Ver 15.1 Distrib 10.1.37-MariaDB, for debian-linux-gnu
(x86_64) using readline 5.2
Apache version: Server version: Apache/2.4.25 (Debian)
Memcached: Servers: undefined | Namespace: undefined | Status: unknown |
Config read from: Nowhere Note that the right place to define the memcached
config is in your $KOHA_CONF file. Currently you do not have a valid
memcached configuration defined. | Effective caching method: Cache::Memory
Zebra version: Zebra 2.0.59 (C) 1994-2014, Index Data Zebra is free
software, covered by the GNU General Public License, and you are welcome to
change it and/or distribute copies of it under certain conditions. SHA1 ID:
c00bfddbf0f3608340d61298acc61dafb167f9b2 Using ICU
Date and time: 05/12/2018 21:36
Time zone: Used: Europe/Berlin | Config: Undefined | Environment (TZ):
Undefined



On Wed, Dec 5, 2018 at 11:30 PM Chris Cormack <chrisc at catalyst.net.nz>
wrote:

> Hi Dilan
>
> There is 17.05, and 17.11 and 18.05 and 18.11.
> So you will need to tell us which actual version of Koha you are running.
>
> (There is no Koha 17 or Koha 18)
>
> Chris
>
> On 6/12/18 9:27 AM, MHE IT admin wrote:
> > Hi,
> >
> > We have just upgraded our Koha 17 to Koha 18. We have one issue, new
> > records added but they are not found in the search. We tried to find a
> > solution but we could not find any reported issue on this.
> >
> > Our library
> > http://library.koyauniversity.org:8080/
> >
> > Please let us know if there anything we can do to solve this problem.
> >
> > Dilan
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
> >
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181205/e409e6dd/attachment-0001.html>

From chrisc at catalyst.net.nz  Wed Dec  5 21:41:23 2018
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Thu, 6 Dec 2018 09:41:23 +1300
Subject: [Koha-devel] Upgrade to Koha 18
In-Reply-To: <CA+O2VWU+ApiNDqdBDC1R3B39pW-KKVb_2WNpcO_k90HM56Yg_A@mail.gmail.com>
References: <CA+O2VWVac8xPGHbRrDGFWaPCSAGO44p4pwu7qS9ovTddcX8e9g@mail.gmail.com>
	<0b154cd2-830d-2c3d-492d-990f9247216b@catalyst.net.nz>
	<CA+O2VWU+ApiNDqdBDC1R3B39pW-KKVb_2WNpcO_k90HM56Yg_A@mail.gmail.com>
Message-ID: <8d9b3b31-6a29-7f0e-a3db-bf4bfacfaefe@catalyst.net.nz>

Hi Dilan

Thanks for that,

Can you check that the koha indexer daemon is running? Did you install
via debian packages?

If so you could do

sudo koha-indexer --restart instancename

(where instancename is your Koha instance name)

Chris

On 6/12/18 9:37 AM, MHE IT admin wrote:
> 
> Sorry to miss that. This is the information I go from the admin?
> 
> Koha version:	18.05.05.000
> OS version ('uname -a'):	Linux koyauniversity.org
> <http://koyauniversity.org> 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6
> (2018-10-08) x86_64
> Perl interpreter:	/usr/bin/perl
> Perl version:	5.024001
> Perl @INC:	/usr/share/koha/lib?
> /etc/perl?
> /usr/local/lib/x86_64-linux-gnu/perl/5.24.1?
> /usr/local/share/perl/5.24.1?
> /usr/lib/x86_64-linux-gnu/perl5/5.24?
> /usr/share/perl5?
> /usr/lib/x86_64-linux-gnu/perl/5.24?
> /usr/share/perl/5.24?
> /usr/local/lib/site_perl?
> /usr/lib/x86_64-linux-gnu/perl-base?
> MySQL version:	mysql Ver 15.1 Distrib 10.1.37-MariaDB, for
> debian-linux-gnu (x86_64) using readline 5.2
> Apache version:	Server version: Apache/2.4.25 (Debian)
> Memcached:	Servers:?undefined?| Namespace:?undefined?| Status:?unknown?|
> Config read from:?Nowhere?Note that the right place to define the
> memcached config is in your $KOHA_CONF file. Currently you do not have a
> valid memcached configuration defined. | Effective caching method:
> Cache::Memory
> Zebra version:	Zebra 2.0.59 (C) 1994-2014, Index Data Zebra is free
> software, covered by the GNU General Public License, and you are welcome
> to change it and/or distribute copies of it under certain conditions.
> SHA1 ID: c00bfddbf0f3608340d61298acc61dafb167f9b2 Using ICU
> Date and time:	05/12/2018 21:36
> Time zone:	Used:?Europe/Berlin?| Config:?Undefined?| Environment
> (TZ):?Undefined
> 
> 
> 
> 
> On Wed, Dec 5, 2018 at 11:30 PM Chris Cormack <chrisc at catalyst.net.nz
> <mailto:chrisc at catalyst.net.nz>> wrote:
> 
>     Hi Dilan
> 
>     There is 17.05, and 17.11 and 18.05 and 18.11.
>     So you will need to tell us which actual version of Koha you are
>     running.
> 
>     (There is no Koha 17 or Koha 18)
> 
>     Chris
> 
>     On 6/12/18 9:27 AM, MHE IT admin wrote:
>     > Hi,?
>     >
>     > We have just upgraded our Koha 17 to Koha 18. We have one issue, new
>     > records added but they are not found in the search. We tried to find a
>     > solution but we could not find any reported issue on this.?
>     >
>     > Our library?
>     > http://library.koyauniversity.org:8080/
>     >
>     > Please let us know if there anything we can do to solve this problem.?
>     >
>     > Dilan
>     >
>     > _______________________________________________
>     > Koha-devel mailing list
>     > Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>     >
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
> 

From admin at mhe-krg.org  Wed Dec  5 21:54:36 2018
From: admin at mhe-krg.org (MHE IT admin)
Date: Wed, 5 Dec 2018 23:54:36 +0300
Subject: [Koha-devel] Upgrade to Koha 18
In-Reply-To: <8d9b3b31-6a29-7f0e-a3db-bf4bfacfaefe@catalyst.net.nz>
References: <CA+O2VWVac8xPGHbRrDGFWaPCSAGO44p4pwu7qS9ovTddcX8e9g@mail.gmail.com>
	<0b154cd2-830d-2c3d-492d-990f9247216b@catalyst.net.nz>
	<CA+O2VWU+ApiNDqdBDC1R3B39pW-KKVb_2WNpcO_k90HM56Yg_A@mail.gmail.com>
	<8d9b3b31-6a29-7f0e-a3db-bf4bfacfaefe@catalyst.net.nz>
Message-ID: <CA+O2VWU15Dt7-pJdGwJ20B6NNg8VWjQBNZi+c_Cg3v_JsT9-Uw@mail.gmail.com>

Thank you, Chris,

I am not sure about that. We hired a system admin to upgrade Koha for us. I
have to ask him tomorrow. What is the command to check whether it is
running so I can check that now, please?

Kind regards




On Wed, Dec 5, 2018 at 11:41 PM Chris Cormack <chrisc at catalyst.net.nz>
wrote:

> Hi Dilan
>
> Thanks for that,
>
> Can you check that the koha indexer daemon is running? Did you install
> via debian packages?
>
> If so you could do
>
> sudo koha-indexer --restart instancename
>
> (where instancename is your Koha instance name)
>
> Chris
>
> On 6/12/18 9:37 AM, MHE IT admin wrote:
> >
> > Sorry to miss that. This is the information I go from the admin
> >
> > Koha version: 18.05.05.000
> > OS version ('uname -a'):      Linux koyauniversity.org
> > <http://koyauniversity.org> 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6
> > (2018-10-08) x86_64
> > Perl interpreter:     /usr/bin/perl
> > Perl version: 5.024001
> > Perl @INC:    /usr/share/koha/lib
> > /etc/perl
> > /usr/local/lib/x86_64-linux-gnu/perl/5.24.1
> > /usr/local/share/perl/5.24.1
> > /usr/lib/x86_64-linux-gnu/perl5/5.24
> > /usr/share/perl5
> > /usr/lib/x86_64-linux-gnu/perl/5.24
> > /usr/share/perl/5.24
> > /usr/local/lib/site_perl
> > /usr/lib/x86_64-linux-gnu/perl-base
> > MySQL version:        mysql Ver 15.1 Distrib 10.1.37-MariaDB, for
> > debian-linux-gnu (x86_64) using readline 5.2
> > Apache version:       Server version: Apache/2.4.25 (Debian)
> > Memcached:    Servers: undefined | Namespace: undefined |
> Status: unknown |
> > Config read from: Nowhere Note that the right place to define the
> > memcached config is in your $KOHA_CONF file. Currently you do not have a
> > valid memcached configuration defined. | Effective caching method:
> > Cache::Memory
> > Zebra version:        Zebra 2.0.59 (C) 1994-2014, Index Data Zebra is
> free
> > software, covered by the GNU General Public License, and you are welcome
> > to change it and/or distribute copies of it under certain conditions.
> > SHA1 ID: c00bfddbf0f3608340d61298acc61dafb167f9b2 Using ICU
> > Date and time:        05/12/2018 21:36
> > Time zone:    Used: Europe/Berlin | Config: Undefined | Environment
> > (TZ): Undefined
> >
> >
> >
> >
> > On Wed, Dec 5, 2018 at 11:30 PM Chris Cormack <chrisc at catalyst.net.nz
> > <mailto:chrisc at catalyst.net.nz>> wrote:
> >
> >     Hi Dilan
> >
> >     There is 17.05, and 17.11 and 18.05 and 18.11.
> >     So you will need to tell us which actual version of Koha you are
> >     running.
> >
> >     (There is no Koha 17 or Koha 18)
> >
> >     Chris
> >
> >     On 6/12/18 9:27 AM, MHE IT admin wrote:
> >     > Hi,
> >     >
> >     > We have just upgraded our Koha 17 to Koha 18. We have one issue,
> new
> >     > records added but they are not found in the search. We tried to
> find a
> >     > solution but we could not find any reported issue on this.
> >     >
> >     > Our library
> >     > http://library.koyauniversity.org:8080/
> >     >
> >     > Please let us know if there anything we can do to solve this
> problem.
> >     >
> >     > Dilan
> >     >
> >     > _______________________________________________
> >     > Koha-devel mailing list
> >     > Koha-devel at lists.koha-community.org
> >     <mailto:Koha-devel at 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/
> >     >
> >     _______________________________________________
> >     Koha-devel mailing list
> >     Koha-devel at lists.koha-community.org
> >     <mailto:Koha-devel at 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/
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181205/de2d0740/attachment.html>

From jonathan.druart at bugs.koha-community.org  Wed Dec  5 22:10:39 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 5 Dec 2018 18:10:39 -0300
Subject: [Koha-devel] Upgrade to Koha 18
In-Reply-To: <CA+O2VWU+ApiNDqdBDC1R3B39pW-KKVb_2WNpcO_k90HM56Yg_A@mail.gmail.com>
References: <CA+O2VWVac8xPGHbRrDGFWaPCSAGO44p4pwu7qS9ovTddcX8e9g@mail.gmail.com>
	<0b154cd2-830d-2c3d-492d-990f9247216b@catalyst.net.nz>
	<CA+O2VWU+ApiNDqdBDC1R3B39pW-KKVb_2WNpcO_k90HM56Yg_A@mail.gmail.com>
Message-ID: <CAJzKNY5W0cLpts0KvO-Wsc9twFHpRXsQqzM9+jQpMQToJV4Pzg@mail.gmail.com>

You really should not ignore the red "Nowhere" part and install (or
configure properly) memcached.


Le mer. 5 d?c. 2018 ? 17:37, MHE IT admin <admin at mhe-krg.org> a ?crit :

>
> Sorry to miss that. This is the information I go from the admin
>
> Koha version: 18.05.05.000
> OS version ('uname -a'): Linux koyauniversity.org 4.9.0-8-amd64 #1 SMP
> Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64
> Perl interpreter: /usr/bin/perl
> Perl version: 5.024001
> Perl @INC: /usr/share/koha/lib
> /etc/perl
> /usr/local/lib/x86_64-linux-gnu/perl/5.24.1
> /usr/local/share/perl/5.24.1
> /usr/lib/x86_64-linux-gnu/perl5/5.24
> /usr/share/perl5
> /usr/lib/x86_64-linux-gnu/perl/5.24
> /usr/share/perl/5.24
> /usr/local/lib/site_perl
> /usr/lib/x86_64-linux-gnu/perl-base
> MySQL version: mysql Ver 15.1 Distrib 10.1.37-MariaDB, for
> debian-linux-gnu (x86_64) using readline 5.2
> Apache version: Server version: Apache/2.4.25 (Debian)
> Memcached: Servers: undefined | Namespace: undefined | Status: unknown |
> Config read from: Nowhere Note that the right place to define the
> memcached config is in your $KOHA_CONF file. Currently you do not have a
> valid memcached configuration defined. | Effective caching method:
> Cache::Memory
> Zebra version: Zebra 2.0.59 (C) 1994-2014, Index Data Zebra is free
> software, covered by the GNU General Public License, and you are welcome to
> change it and/or distribute copies of it under certain conditions. SHA1 ID:
> c00bfddbf0f3608340d61298acc61dafb167f9b2 Using ICU
> Date and time: 05/12/2018 21:36
> Time zone: Used: Europe/Berlin | Config: Undefined | Environment (TZ):
> Undefined
>
>
>
> On Wed, Dec 5, 2018 at 11:30 PM Chris Cormack <chrisc at catalyst.net.nz>
> wrote:
>
>> Hi Dilan
>>
>> There is 17.05, and 17.11 and 18.05 and 18.11.
>> So you will need to tell us which actual version of Koha you are running.
>>
>> (There is no Koha 17 or Koha 18)
>>
>> Chris
>>
>> On 6/12/18 9:27 AM, MHE IT admin wrote:
>> > Hi,
>> >
>> > We have just upgraded our Koha 17 to Koha 18. We have one issue, new
>> > records added but they are not found in the search. We tried to find a
>> > solution but we could not find any reported issue on this.
>> >
>> > Our library
>> > http://library.koyauniversity.org:8080/
>> >
>> > Please let us know if there anything we can do to solve this problem.
>> >
>> > Dilan
>> >
>> > _______________________________________________
>> > Koha-devel mailing list
>> > Koha-devel at 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/
>> >
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181205/91dd0b13/attachment-0001.html>

From jonathan.druart at bugs.koha-community.org  Wed Dec  5 22:44:09 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 5 Dec 2018 18:44:09 -0300
Subject: [Koha-devel] Bugzilla search question
In-Reply-To: <CAMSJbVvzciCBPvO2DSejNbkEvsc=8dZ4LfOKU-0VUfg4KaHMiw@mail.gmail.com>
References: <CAMSJbVvzciCBPvO2DSejNbkEvsc=8dZ4LfOKU-0VUfg4KaHMiw@mail.gmail.com>
Message-ID: <CAJzKNY6vzYSy+RHAxv0iouY1ctBnN=fy1bdamu_8V-QOmfigxA@mail.gmail.com>

Hi Barton,
That could certainly be done easily using Greasemonkey.
Let me know if you need help.
Cheers,
Jonathan
Le mar. 27 nov. 2018 ? 20:26, Barton Chittenden
<barton at bywatersolutions.com> a ?crit :
>
> Is there any way to change the default statuses on the bugzilla advanced search page? https://bugs.koha-community.org/bugzilla3/query.cgi
>
> The default statuses searched are NEW, REOPENED and ASSIGNED... which skips bugs that are 'In Discussion', 'Needs Signoff', 'Signed off', 'Passed QA', 'Pushed for QA', 'Failed QA', 'Patch doesn't apply' or 'Pushed to (Mater|Stable)'... in other words, most of the statuses that we use the most.
>
> I'd prefer to customize this on my own account, but it certainly wouldn't hurt my feelings if the changes were made globally.
>
> Thanks,
>
> --Barton
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From M.de.Rooy at rijksmuseum.nl  Thu Dec  6 08:15:02 2018
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 6 Dec 2018 07:15:02 +0000
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
Message-ID: <AM6PR05MB59763454702C92D6FC1239F7CEA90@AM6PR05MB5976.eurprd05.prod.outlook.com>

+1

________________________________
Van: koha-devel-bounces at lists.koha-community.org <koha-devel-bounces at lists.koha-community.org> namens Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Verzonden: woensdag 5 december 2018 20:20:35
Aan: koha-devel
Onderwerp: [Koha-devel] Cache::Memory must be removed (21955)

Hi devs,

I am still recovering from my holidays and I think I caught a quite big fish.

After an interesting track game I will explain why I am suggesting to
remove Cache::Memory that is currently used as fallback for the L2
cache.

What I tried to fix:
Jenkins is complaining about selenium tests (regressions.t) failing on
18.05, it is a succession of events and bugs that were not linked at
first glance.

Here are the different steps I went though:
- On bug 21426 we noticed that USE_MEMCACHED was not taken into
account. If set to "no" the default memcached config was defined in
the koha-config.xml file anyway
- A new regression selenium test was added on bug 21777 to catch the
presence of an audio alert on the circulation page
- Investigating the failing tests I noticed that koha-testing-docker
was not setting the memcached config on the 18.05 branches (I guess
the image has not been rebuilt yet)
search_utf8.t output "Warning: script running in daemon mode, without
recommended caching system (memcached)."
- I also find that [% Koha.Preference('AudioAlerts') %] did not return
the value set by the tests, but the value that the DB has before the
tests were launched
=> It is a cache issue!
- ...but only when memcached is not set...
- Reading Koha::Cache->new we can notice that Cache::Memory is used
for the L2 cache when memcached is not defined in the config

And so we have the problem: If a value is set in the cache by a Plack
worker, it will not be available from another one, as the L2 cache is
not shared (!)

To recreate easily the problem you can:
- remove the memcached config
- edit intranet-bottom.inc and add
===[% Koha.Preference('AudioAlerts') %]===
- restart plack
- Modify the value of AudioAlerts (using the UI)
- Reload the page (reload several times if the value is still correct,
it will depend on which worker will serve the request)

Solution:
I am considering removing Cache::Memory unless somebody else has a better idea
Bug 21955 - Cache::Memory should not be used as L2 cache

Note that it should not affect a lot of people as everybody is
supposed to have memcached configured and working correctly!

Cheers,
Jonathan
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181206/51a76886/attachment.html>

From fridolin.somers at biblibre.com  Thu Dec  6 09:25:50 2018
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 6 Dec 2018 09:25:50 +0100
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
Message-ID: <10f897bb-f31f-620e-c4d2-0432951d19d2@biblibre.com>

Indeed, this is a big behavior error we found a few month ago.
I think we shared it in mailing but I can find how.
This is a big issue when you change an HTML systempreference like 
"opacnav", you see the change and when refresh its gone (you see the 
other plack worker).
We solved by installing memached everywhere.

Maybe we can just disable Cache::Memory when Plack mode is used.
Then I say we need a C4::Context->is_psgi() method :
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76477

Programing is sometimes so wierd ;)

Regards,

Le 05/12/2018 ? 20:20, Jonathan Druart a ?crit?:
> Hi devs,
> 
> I am still recovering from my holidays and I think I caught a quite big fish.
> 
> After an interesting track game I will explain why I am suggesting to
> remove Cache::Memory that is currently used as fallback for the L2
> cache.
> 
> What I tried to fix:
> Jenkins is complaining about selenium tests (regressions.t) failing on
> 18.05, it is a succession of events and bugs that were not linked at
> first glance.
> 
> Here are the different steps I went though:
> - On bug 21426 we noticed that USE_MEMCACHED was not taken into
> account. If set to "no" the default memcached config was defined in
> the koha-config.xml file anyway
> - A new regression selenium test was added on bug 21777 to catch the
> presence of an audio alert on the circulation page
> - Investigating the failing tests I noticed that koha-testing-docker
> was not setting the memcached config on the 18.05 branches (I guess
> the image has not been rebuilt yet)
> search_utf8.t output "Warning: script running in daemon mode, without
> recommended caching system (memcached)."
> - I also find that [% Koha.Preference('AudioAlerts') %] did not return
> the value set by the tests, but the value that the DB has before the
> tests were launched
> => It is a cache issue!
> - ...but only when memcached is not set...
> - Reading Koha::Cache->new we can notice that Cache::Memory is used
> for the L2 cache when memcached is not defined in the config
> 
> And so we have the problem: If a value is set in the cache by a Plack
> worker, it will not be available from another one, as the L2 cache is
> not shared (!)
> 
> To recreate easily the problem you can:
> - remove the memcached config
> - edit intranet-bottom.inc and add
> ===[% Koha.Preference('AudioAlerts') %]===
> - restart plack
> - Modify the value of AudioAlerts (using the UI)
> - Reload the page (reload several times if the value is still correct,
> it will depend on which worker will serve the request)
> 
> Solution:
> I am considering removing Cache::Memory unless somebody else has a better idea
> Bug 21955 - Cache::Memory should not be used as L2 cache
> 
> Note that it should not affect a lot of people as everybody is
> supposed to have memcached configured and working correctly!
> 
> Cheers,
> Jonathan
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
BibLibre, France - software and system maintainer

From martin.renvoize at ptfs-europe.com  Thu Dec  6 10:24:47 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Thu, 6 Dec 2018 09:24:47 +0000
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <10f897bb-f31f-620e-c4d2-0432951d19d2@biblibre.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<10f897bb-f31f-620e-c4d2-0432951d19d2@biblibre.com>
Message-ID: <CAB7SL8AvqxZYFdpZFkrmnTo4msMpjTxih49ysCp+utzyG8e+2Q@mail.gmail.com>

I agree on its removal too.

On Thu, 6 Dec 2018, 8:26 am Fridolin SOMERS <fridolin.somers at biblibre.com
wrote:

> Indeed, this is a big behavior error we found a few month ago.
> I think we shared it in mailing but I can find how.
> This is a big issue when you change an HTML systempreference like
> "opacnav", you see the change and when refresh its gone (you see the
> other plack worker).
> We solved by installing memached everywhere.
>
> Maybe we can just disable Cache::Memory when Plack mode is used.
> Then I say we need a C4::Context->is_psgi() method :
> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76477
>
> Programing is sometimes so wierd ;)
>
> Regards,
>
> Le 05/12/2018 ? 20:20, Jonathan Druart a ?crit :
> > Hi devs,
> >
> > I am still recovering from my holidays and I think I caught a quite big
> fish.
> >
> > After an interesting track game I will explain why I am suggesting to
> > remove Cache::Memory that is currently used as fallback for the L2
> > cache.
> >
> > What I tried to fix:
> > Jenkins is complaining about selenium tests (regressions.t) failing on
> > 18.05, it is a succession of events and bugs that were not linked at
> > first glance.
> >
> > Here are the different steps I went though:
> > - On bug 21426 we noticed that USE_MEMCACHED was not taken into
> > account. If set to "no" the default memcached config was defined in
> > the koha-config.xml file anyway
> > - A new regression selenium test was added on bug 21777 to catch the
> > presence of an audio alert on the circulation page
> > - Investigating the failing tests I noticed that koha-testing-docker
> > was not setting the memcached config on the 18.05 branches (I guess
> > the image has not been rebuilt yet)
> > search_utf8.t output "Warning: script running in daemon mode, without
> > recommended caching system (memcached)."
> > - I also find that [% Koha.Preference('AudioAlerts') %] did not return
> > the value set by the tests, but the value that the DB has before the
> > tests were launched
> > => It is a cache issue!
> > - ...but only when memcached is not set...
> > - Reading Koha::Cache->new we can notice that Cache::Memory is used
> > for the L2 cache when memcached is not defined in the config
> >
> > And so we have the problem: If a value is set in the cache by a Plack
> > worker, it will not be available from another one, as the L2 cache is
> > not shared (!)
> >
> > To recreate easily the problem you can:
> > - remove the memcached config
> > - edit intranet-bottom.inc and add
> > ===[% Koha.Preference('AudioAlerts') %]===
> > - restart plack
> > - Modify the value of AudioAlerts (using the UI)
> > - Reload the page (reload several times if the value is still correct,
> > it will depend on which worker will serve the request)
> >
> > Solution:
> > I am considering removing Cache::Memory unless somebody else has a
> better idea
> > Bug 21955 - Cache::Memory should not be used as L2 cache
> >
> > Note that it should not affect a lot of people as everybody is
> > supposed to have memcached configured and working correctly!
> >
> > Cheers,
> > Jonathan
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
> >
>
> --
> Fridolin SOMERS <fridolin.somers at biblibre.com>
> BibLibre, France - software and system maintainer
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181206/a5b4f70d/attachment.html>

From tomascohen at gmail.com  Thu Dec  6 16:44:18 2018
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 6 Dec 2018 12:44:18 -0300
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
Message-ID: <CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>

Get rid of it!

+1

El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart (<
jonathan.druart at bugs.koha-community.org>) escribi?:

> Hi devs,
>
> I am still recovering from my holidays and I think I caught a quite big
> fish.
>
> After an interesting track game I will explain why I am suggesting to
> remove Cache::Memory that is currently used as fallback for the L2
> cache.
>
> What I tried to fix:
> Jenkins is complaining about selenium tests (regressions.t) failing on
> 18.05, it is a succession of events and bugs that were not linked at
> first glance.
>
> Here are the different steps I went though:
> - On bug 21426 we noticed that USE_MEMCACHED was not taken into
> account. If set to "no" the default memcached config was defined in
> the koha-config.xml file anyway
> - A new regression selenium test was added on bug 21777 to catch the
> presence of an audio alert on the circulation page
> - Investigating the failing tests I noticed that koha-testing-docker
> was not setting the memcached config on the 18.05 branches (I guess
> the image has not been rebuilt yet)
> search_utf8.t output "Warning: script running in daemon mode, without
> recommended caching system (memcached)."
> - I also find that [% Koha.Preference('AudioAlerts') %] did not return
> the value set by the tests, but the value that the DB has before the
> tests were launched
> => It is a cache issue!
> - ...but only when memcached is not set...
> - Reading Koha::Cache->new we can notice that Cache::Memory is used
> for the L2 cache when memcached is not defined in the config
>
> And so we have the problem: If a value is set in the cache by a Plack
> worker, it will not be available from another one, as the L2 cache is
> not shared (!)
>
> To recreate easily the problem you can:
> - remove the memcached config
> - edit intranet-bottom.inc and add
> ===[% Koha.Preference('AudioAlerts') %]===
> - restart plack
> - Modify the value of AudioAlerts (using the UI)
> - Reload the page (reload several times if the value is still correct,
> it will depend on which worker will serve the request)
>
> Solution:
> I am considering removing Cache::Memory unless somebody else has a better
> idea
> Bug 21955 - Cache::Memory should not be used as L2 cache
>
> Note that it should not affect a lot of people as everybody is
> supposed to have memcached configured and working correctly!
>
> Cheers,
> Jonathan
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>


-- 
Tom?s Cohen Arazi
Theke Solutions (http://theke.io)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181206/1d0f1921/attachment.html>

From jonathan.druart at bugs.koha-community.org  Thu Dec  6 17:05:06 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Thu, 6 Dec 2018 13:05:06 -0300
Subject: [Koha-devel] Ease the write of our tests
Message-ID: <CAJzKNY7Gj1Jk9nLXVFLfbgrJqQ8Oy__ZUo9Qzh7f+iA8QOntrg@mail.gmail.com>

Hi devs,

I thought I adverted it here already but I did not, so here it is!

I have started to clean up a bit our tests, in order to make them
easier to write and avoid silly copy/paste, or create too many things
before starting to write the interesting parts.

There is an omnibus
Bug 21816 - [OMNIBUS] Ease the write of our tests

And so far 2 bug reports:
Bug 21798 - We need t::lib::TestBuilder::gimme_a_biblio
Bug 21817 - Mock userenv should be a t::lib::Mocks method

I really would like to see those two getting a bit of love to avoid
unnecessary rebases, and let me continue the work for other
refactoring subroutines.

Cheers,
Jonathan

From dcook at prosentient.com.au  Fri Dec  7 00:52:50 2018
From: dcook at prosentient.com.au (David Cook)
Date: Fri, 7 Dec 2018 10:52:50 +1100
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
Message-ID: <03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>

I?ve noticed some caching issues but haven?t had time to investigate too deeply. I wonder if this relates to what I?ve encountered.

 

In any case, +1!

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Tomas Cohen Arazi
Sent: Friday, 7 December 2018 2:44 AM
To: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Cc: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Cache::Memory must be removed (21955)

 

Get rid of it!

 

+1

 

El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart (<jonathan.druart at bugs.koha-community.org <mailto:jonathan.druart at bugs.koha-community.org> >) escribi?:

Hi devs,

I am still recovering from my holidays and I think I caught a quite big fish.

After an interesting track game I will explain why I am suggesting to
remove Cache::Memory that is currently used as fallback for the L2
cache.

What I tried to fix:
Jenkins is complaining about selenium tests (regressions.t) failing on
18.05, it is a succession of events and bugs that were not linked at
first glance.

Here are the different steps I went though:
- On bug 21426 we noticed that USE_MEMCACHED was not taken into
account. If set to "no" the default memcached config was defined in
the koha-config.xml file anyway
- A new regression selenium test was added on bug 21777 to catch the
presence of an audio alert on the circulation page
- Investigating the failing tests I noticed that koha-testing-docker
was not setting the memcached config on the 18.05 branches (I guess
the image has not been rebuilt yet)
search_utf8.t output "Warning: script running in daemon mode, without
recommended caching system (memcached)."
- I also find that [% Koha.Preference('AudioAlerts') %] did not return
the value set by the tests, but the value that the DB has before the
tests were launched
=> It is a cache issue!
- ...but only when memcached is not set...
- Reading Koha::Cache->new we can notice that Cache::Memory is used
for the L2 cache when memcached is not defined in the config

And so we have the problem: If a value is set in the cache by a Plack
worker, it will not be available from another one, as the L2 cache is
not shared (!)

To recreate easily the problem you can:
- remove the memcached config
- edit intranet-bottom.inc and add
===[% Koha.Preference('AudioAlerts') %]===
- restart plack
- Modify the value of AudioAlerts (using the UI)
- Reload the page (reload several times if the value is still correct,
it will depend on which worker will serve the request)

Solution:
I am considering removing Cache::Memory unless somebody else has a better idea
Bug 21955 - Cache::Memory should not be used as L2 cache

Note that it should not affect a lot of people as everybody is
supposed to have memcached configured and working correctly!

Cheers,
Jonathan
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at 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/




 

-- 

Tom?s Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
? +54 9351 3513384
GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181207/50fd567a/attachment-0001.html>

From ere.maijala at helsinki.fi  Fri Dec  7 08:55:39 2018
From: ere.maijala at helsinki.fi (Ere Maijala)
Date: Fri, 7 Dec 2018 09:55:39 +0200
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
Message-ID: <467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>

I'm a bit hesitant on this. I understand running without a cache makes
things like tests easier, but Cache::Memory is actually a pretty useful
fallback. There's a lot of code in Koha that does redundant fetches of
e.g. framework data, and without caching I'm afraid it will slow down
significantly. Cache::Memory is very handy when developing stuff to
speed up execution of e.g. batch utilities when you don't want to mess
with constantly flushing Memcached.

I would like to propose another approach for considerarion: disable
Cache::Memory only if running under Plack.

--Ere

David Cook kirjoitti 7.12.2018 klo 1.52:
> I?ve noticed some caching issues but haven?t had time to investigate too
> deeply. I wonder if this relates to what I?ve encountered.
> 
> ?
> 
> In any case, +1!
> 
> ?
> 
> David Cook
> 
> Systems Librarian
> 
> Prosentient Systems
> 
> 72/330 Wattle St
> 
> Ultimo, NSW 2007
> 
> Australia
> 
> ?
> 
> Office: 02 9212 0899
> 
> Direct: 02 8005 0595
> 
> ?
> 
> *From:*koha-devel-bounces at lists.koha-community.org
> [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
> *Tomas Cohen Arazi
> *Sent:* Friday, 7 December 2018 2:44 AM
> *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
> 
> ?
> 
> Get rid of it!
> 
> ?
> 
> +1
> 
> ?
> 
> El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
> (<jonathan.druart at bugs.koha-community.org
> <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
> 
>     Hi devs,
> 
>     I am still recovering from my holidays and I think I caught a quite
>     big fish.
> 
>     After an interesting track game I will explain why I am suggesting to
>     remove Cache::Memory that is currently used as fallback for the L2
>     cache.
> 
>     What I tried to fix:
>     Jenkins is complaining about selenium tests (regressions.t) failing on
>     18.05, it is a succession of events and bugs that were not linked at
>     first glance.
> 
>     Here are the different steps I went though:
>     - On bug 21426 we noticed that USE_MEMCACHED was not taken into
>     account. If set to "no" the default memcached config was defined in
>     the koha-config.xml file anyway
>     - A new regression selenium test was added on bug 21777 to catch the
>     presence of an audio alert on the circulation page
>     - Investigating the failing tests I noticed that koha-testing-docker
>     was not setting the memcached config on the 18.05 branches (I guess
>     the image has not been rebuilt yet)
>     search_utf8.t output "Warning: script running in daemon mode, without
>     recommended caching system (memcached)."
>     - I also find that [% Koha.Preference('AudioAlerts') %] did not return
>     the value set by the tests, but the value that the DB has before the
>     tests were launched
>     => It is a cache issue!
>     - ...but only when memcached is not set...
>     - Reading Koha::Cache->new we can notice that Cache::Memory is used
>     for the L2 cache when memcached is not defined in the config
> 
>     And so we have the problem: If a value is set in the cache by a Plack
>     worker, it will not be available from another one, as the L2 cache is
>     not shared (!)
> 
>     To recreate easily the problem you can:
>     - remove the memcached config
>     - edit intranet-bottom.inc and add
>     ===[% Koha.Preference('AudioAlerts') %]===
>     - restart plack
>     - Modify the value of AudioAlerts (using the UI)
>     - Reload the page (reload several times if the value is still correct,
>     it will depend on which worker will serve the request)
> 
>     Solution:
>     I am considering removing Cache::Memory unless somebody else has a
>     better idea
>     Bug 21955 - Cache::Memory should not be used as L2 cache
> 
>     Note that it should not affect a lot of people as everybody is
>     supposed to have memcached configured and working correctly!
> 
>     Cheers,
>     Jonathan
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
> 
> 
> ?
> 
> -- 
> 
> Tom?s Cohen Arazi
> 
> Theke Solutions (http://theke.io <http://theke.io/>)
> ?+54 9351 3513384
> GPG: B2F3C15F
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

-- 
Ere Maijala
Kansalliskirjasto / The National Library of Finland


From kyle.m.hall at gmail.com  Fri Dec  7 14:24:14 2018
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Fri, 7 Dec 2018 08:24:14 -0500
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
Message-ID: <CACpVHfx5CS6m6CnGZXNXHm=25R5xfhkn6FgbO713KCTnw3tzgg@mail.gmail.com>

+1
---
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )


On Wed, Dec 5, 2018 at 2:20 PM Jonathan Druart <
jonathan.druart at bugs.koha-community.org> wrote:

> Hi devs,
>
> I am still recovering from my holidays and I think I caught a quite big
> fish.
>
> After an interesting track game I will explain why I am suggesting to
> remove Cache::Memory that is currently used as fallback for the L2
> cache.
>
> What I tried to fix:
> Jenkins is complaining about selenium tests (regressions.t) failing on
> 18.05, it is a succession of events and bugs that were not linked at
> first glance.
>
> Here are the different steps I went though:
> - On bug 21426 we noticed that USE_MEMCACHED was not taken into
> account. If set to "no" the default memcached config was defined in
> the koha-config.xml file anyway
> - A new regression selenium test was added on bug 21777 to catch the
> presence of an audio alert on the circulation page
> - Investigating the failing tests I noticed that koha-testing-docker
> was not setting the memcached config on the 18.05 branches (I guess
> the image has not been rebuilt yet)
> search_utf8.t output "Warning: script running in daemon mode, without
> recommended caching system (memcached)."
> - I also find that [% Koha.Preference('AudioAlerts') %] did not return
> the value set by the tests, but the value that the DB has before the
> tests were launched
> => It is a cache issue!
> - ...but only when memcached is not set...
> - Reading Koha::Cache->new we can notice that Cache::Memory is used
> for the L2 cache when memcached is not defined in the config
>
> And so we have the problem: If a value is set in the cache by a Plack
> worker, it will not be available from another one, as the L2 cache is
> not shared (!)
>
> To recreate easily the problem you can:
> - remove the memcached config
> - edit intranet-bottom.inc and add
> ===[% Koha.Preference('AudioAlerts') %]===
> - restart plack
> - Modify the value of AudioAlerts (using the UI)
> - Reload the page (reload several times if the value is still correct,
> it will depend on which worker will serve the request)
>
> Solution:
> I am considering removing Cache::Memory unless somebody else has a better
> idea
> Bug 21955 - Cache::Memory should not be used as L2 cache
>
> Note that it should not affect a lot of people as everybody is
> supposed to have memcached configured and working correctly!
>
> Cheers,
> Jonathan
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181207/b5213728/attachment.html>

From josef.moravec at gmail.com  Fri Dec  7 15:40:15 2018
From: josef.moravec at gmail.com (Josef Moravec)
Date: Fri, 7 Dec 2018 15:40:15 +0100
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CACpVHfx5CS6m6CnGZXNXHm=25R5xfhkn6FgbO713KCTnw3tzgg@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CACpVHfx5CS6m6CnGZXNXHm=25R5xfhkn6FgbO713KCTnw3tzgg@mail.gmail.com>
Message-ID: <CAOvd_x+_m7f0+aOOtE+0Npr5dXuF5W2_SNUeLWbjPM4bXt9HiQ@mail.gmail.com>

As the plack is recomended way of running Koha, I am for removing
Cache::Memory too

Josef

On Fri, Dec 7, 2018 at 2:24 PM Kyle Hall <kyle.m.hall at gmail.com> wrote:

> +1
> ---
> http://www.kylehall.info
> ByWater Solutions ( http://bywatersolutions.com )
> Meadville Public Library ( http://www.meadvillelibrary.org )
> Crawford County Federated Library System ( http://www.ccfls.org )
>
>
> On Wed, Dec 5, 2018 at 2:20 PM Jonathan Druart <
> jonathan.druart at bugs.koha-community.org> wrote:
>
>> Hi devs,
>>
>> I am still recovering from my holidays and I think I caught a quite big
>> fish.
>>
>> After an interesting track game I will explain why I am suggesting to
>> remove Cache::Memory that is currently used as fallback for the L2
>> cache.
>>
>> What I tried to fix:
>> Jenkins is complaining about selenium tests (regressions.t) failing on
>> 18.05, it is a succession of events and bugs that were not linked at
>> first glance.
>>
>> Here are the different steps I went though:
>> - On bug 21426 we noticed that USE_MEMCACHED was not taken into
>> account. If set to "no" the default memcached config was defined in
>> the koha-config.xml file anyway
>> - A new regression selenium test was added on bug 21777 to catch the
>> presence of an audio alert on the circulation page
>> - Investigating the failing tests I noticed that koha-testing-docker
>> was not setting the memcached config on the 18.05 branches (I guess
>> the image has not been rebuilt yet)
>> search_utf8.t output "Warning: script running in daemon mode, without
>> recommended caching system (memcached)."
>> - I also find that [% Koha.Preference('AudioAlerts') %] did not return
>> the value set by the tests, but the value that the DB has before the
>> tests were launched
>> => It is a cache issue!
>> - ...but only when memcached is not set...
>> - Reading Koha::Cache->new we can notice that Cache::Memory is used
>> for the L2 cache when memcached is not defined in the config
>>
>> And so we have the problem: If a value is set in the cache by a Plack
>> worker, it will not be available from another one, as the L2 cache is
>> not shared (!)
>>
>> To recreate easily the problem you can:
>> - remove the memcached config
>> - edit intranet-bottom.inc and add
>> ===[% Koha.Preference('AudioAlerts') %]===
>> - restart plack
>> - Modify the value of AudioAlerts (using the UI)
>> - Reload the page (reload several times if the value is still correct,
>> it will depend on which worker will serve the request)
>>
>> Solution:
>> I am considering removing Cache::Memory unless somebody else has a better
>> idea
>> Bug 21955 - Cache::Memory should not be used as L2 cache
>>
>> Note that it should not affect a lot of people as everybody is
>> supposed to have memcached configured and working correctly!
>>
>> Cheers,
>> Jonathan
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/



-- 
Josef Moravec
josef.moravec at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181207/b7056c2e/attachment.html>

From jonathan.druart at bugs.koha-community.org  Fri Dec  7 16:36:53 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 7 Dec 2018 12:36:53 -0300
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
	<467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
Message-ID: <CAJzKNY6s4c9uznyd1G0ZwRm66QucYhE_MGQGcp2zPnLf3sB7RA@mail.gmail.com>

I talked with Ere on IRC, but prefer to let a note here as well.

Enabling Cache::Memory if Plack is not running will not help as we
have the L1 (in memory) cache, which is used in any cases (and flushed
under Plack before a request is made).

I do not know how is our caching system understood by the team. I can
try and write something on the wiki if it can help. Hint: there is no
black magic :)

Cheers,
Jonathan

Le ven. 7 d?c. 2018 ? 04:55, Ere Maijala <ere.maijala at helsinki.fi> a ?crit :
>
> I'm a bit hesitant on this. I understand running without a cache makes
> things like tests easier, but Cache::Memory is actually a pretty useful
> fallback. There's a lot of code in Koha that does redundant fetches of
> e.g. framework data, and without caching I'm afraid it will slow down
> significantly. Cache::Memory is very handy when developing stuff to
> speed up execution of e.g. batch utilities when you don't want to mess
> with constantly flushing Memcached.
>
> I would like to propose another approach for considerarion: disable
> Cache::Memory only if running under Plack.
>
> --Ere
>
> David Cook kirjoitti 7.12.2018 klo 1.52:
> > I?ve noticed some caching issues but haven?t had time to investigate too
> > deeply. I wonder if this relates to what I?ve encountered.
> >
> >
> >
> > In any case, +1!
> >
> >
> >
> > David Cook
> >
> > Systems Librarian
> >
> > Prosentient Systems
> >
> > 72/330 Wattle St
> >
> > Ultimo, NSW 2007
> >
> > Australia
> >
> >
> >
> > Office: 02 9212 0899
> >
> > Direct: 02 8005 0595
> >
> >
> >
> > *From:*koha-devel-bounces at lists.koha-community.org
> > [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
> > *Tomas Cohen Arazi
> > *Sent:* Friday, 7 December 2018 2:44 AM
> > *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
> > *Cc:* koha-devel <koha-devel at lists.koha-community.org>
> > *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
> >
> >
> >
> > Get rid of it!
> >
> >
> >
> > +1
> >
> >
> >
> > El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
> > (<jonathan.druart at bugs.koha-community.org
> > <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
> >
> >     Hi devs,
> >
> >     I am still recovering from my holidays and I think I caught a quite
> >     big fish.
> >
> >     After an interesting track game I will explain why I am suggesting to
> >     remove Cache::Memory that is currently used as fallback for the L2
> >     cache.
> >
> >     What I tried to fix:
> >     Jenkins is complaining about selenium tests (regressions.t) failing on
> >     18.05, it is a succession of events and bugs that were not linked at
> >     first glance.
> >
> >     Here are the different steps I went though:
> >     - On bug 21426 we noticed that USE_MEMCACHED was not taken into
> >     account. If set to "no" the default memcached config was defined in
> >     the koha-config.xml file anyway
> >     - A new regression selenium test was added on bug 21777 to catch the
> >     presence of an audio alert on the circulation page
> >     - Investigating the failing tests I noticed that koha-testing-docker
> >     was not setting the memcached config on the 18.05 branches (I guess
> >     the image has not been rebuilt yet)
> >     search_utf8.t output "Warning: script running in daemon mode, without
> >     recommended caching system (memcached)."
> >     - I also find that [% Koha.Preference('AudioAlerts') %] did not return
> >     the value set by the tests, but the value that the DB has before the
> >     tests were launched
> >     => It is a cache issue!
> >     - ...but only when memcached is not set...
> >     - Reading Koha::Cache->new we can notice that Cache::Memory is used
> >     for the L2 cache when memcached is not defined in the config
> >
> >     And so we have the problem: If a value is set in the cache by a Plack
> >     worker, it will not be available from another one, as the L2 cache is
> >     not shared (!)
> >
> >     To recreate easily the problem you can:
> >     - remove the memcached config
> >     - edit intranet-bottom.inc and add
> >     ===[% Koha.Preference('AudioAlerts') %]===
> >     - restart plack
> >     - Modify the value of AudioAlerts (using the UI)
> >     - Reload the page (reload several times if the value is still correct,
> >     it will depend on which worker will serve the request)
> >
> >     Solution:
> >     I am considering removing Cache::Memory unless somebody else has a
> >     better idea
> >     Bug 21955 - Cache::Memory should not be used as L2 cache
> >
> >     Note that it should not affect a lot of people as everybody is
> >     supposed to have memcached configured and working correctly!
> >
> >     Cheers,
> >     Jonathan
> >     _______________________________________________
> >     Koha-devel mailing list
> >     Koha-devel at lists.koha-community.org
> >     <mailto:Koha-devel at 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/
> >
> >
> >
> >
> > --
> >
> > Tom?s Cohen Arazi
> >
> > Theke Solutions (http://theke.io <http://theke.io/>)
> > ?+54 9351 3513384
> > GPG: B2F3C15F
> >
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
> >
>
> --
> Ere Maijala
> Kansalliskirjasto / The National Library of Finland
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From dcook at prosentient.com.au  Mon Dec 10 01:15:03 2018
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 10 Dec 2018 11:15:03 +1100
Subject: [Koha-devel] Autorenewals renewing an item then sending a renew
	failure email the next day
In-Reply-To: <df3ebbd5e0734950875988c9a7952f4d@nExchange2.hsg.intra>
References: <00c401d47d68$f2c27cd0$d8477670$@prosentient.com.au>	<ed0ac08a1d1540c3aed3d8f1127ab66d@nExchange2.hsg.intra>	<000201d486b0$b967f130$2c37d390$@prosentient.com.au>	<eb6f156e113143b38699672e2e9c3251@nExchange2.hsg.intra>	<005501d4883c$3a534ce0$aef9e6a0$@prosentient.com.au>	<15BB8384-4CC4-4768-AFC7-2715A19001AD@su.se>	<015301d48a9c$2b960410$82c20c30$@prosentient.com.au>
	<df3ebbd5e0734950875988c9a7952f4d@nExchange2.hsg.intra>
Message-ID: <005c01d4901d$65cd4630$3167d290$@prosentient.com.au>

Hi Holger,

I think you're right about notices being disabled by default. Looking at debian/koha-common.cron.daily I don't see the "--send-notices" flag which is being used by the non-Debian libraries I support. 

I think turning off notices will probably be the advice I give from now on, and hopefully that's well received, as this looks like a difficult issue for gaining consensus. 

Ah, that's a good point about CanBookBeRenewed affecting other things than just autorenewals. (One reason I didn't want to write a patch locally was the possibility of unintended consequences I didn't foresee, so I'm glad that you mentioned that!)

I'll have to think more about this one, but for now I'll just recommend that my libraries turn off the notices. 

Thanks for your input!

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Holger Meissner
Sent: Wednesday, 5 December 2018 8:20 PM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

I seem to have trouble sending emails, let's try plain text this time. I'm sorry if you receive multiple messages.

Well, I contributed the original thing (Bug 11577) but not the AUTO_RENEWALS notification. I assumed that this new notification was optional and disabled by default. Seems that I was wrong there? Probably cait disabled it locally for us, before we even noticed :)

So just syspref the notification for now? What do you people at ByWater and PTFS Europe say? Did 15705 get pushed by accident, still missing a way to disable notification?

It really should be optional. I?m still not convinced it's illogical - if libraries for some reason want to autorenew verbosely. We don't, but I suppose you?d just have to be very careful with the wording of the e-mail. Especially in a big library with title level holds. I can see it being quite annoying in that use case.

Here's what I'm worried about: Rearranging the error precedence in CanBookBeRenewed wouldn't just affect autorenewals, it would affect all issues and how they are displayed in opac and in staff client.

> If you want to notify patrons when someone places a hold on their loan 
> so that they can decide to return it out of courtesy, I?d recommend 
> making adding a different feature for that

I think that's actually a great idea! Equal notification for all holds. Yet, it would be confusing if a patron is notified, then logs into opac and can't see the holds they were notified about. Also, I want to see holds in staff client as soon as they are placed. If you don't, then making the error precedence configurable might be a solution.

Another wild idea, if really necessary make CanBookBeReturned return multiple reasons. Maybe using a bit field, to speed up the extra work as much as possible and easily check for any combination of renewal errors. Or maybe just using new ?too soon and on hold? and ?auto too soon and on hold? errors.

Regards,
Holger


Von: David Cook <dcook at prosentient.com.au>
Gesendet: Montag, 3. Dezember 2018 01:07
An: 'Andreas Hedstr?m Mace' <andreas.hedstrom.mace at su.se>; Holger Meissner <Holger.Meissner at hs-gesundheit.de>; koha-devel at lists.koha-community.org
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi Andreas,

Can someone post a patch for your local fix? It?s my intention to write a patch at some point, but I?ve had a number of other tasks occupying my attention lately (as well as being off sick). I?d be happy to test an existing patch though. 

As the original author of the function, I?d like to hear more from Holger. It looks like Hochschule f?r Gesundheit sponsored the patch as well? So I?m guessing that the current way it functions must be working for them. I?d hate to break functionality that is working for someone. I?m thinking adding configurability of the ordering of steps might be the best bet. What do you think, Holger? 

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595

From: Andreas Hedstr?m Mace [mailto:andreas.hedstrom.mace at su.se]
Sent: Friday, 30 November 2018 7:54 PM
To: David Cook <mailto:dcook at prosentient.com.au>; 'Holger Meissner' <mailto:Holger.Meissner at hs-gesundheit.de>; mailto:koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Hi all!

In general, I agree with David?s conclusions. We had plenty of confusion from patrons when first implementing autorenewals, and have now fixed it locally.

Since we are a fairly large academic library, for popular material there will ususally be several copies of a book, where each of these can fill a placed hold. So sending out an email that it won?t be autorenewed far ahead of the due date to all the patrons doesn?t make much sense, since the hold might be cancelled or filled by another copy by the time it is actually tries to renew (as set by ?no renewal before? in the circulation rules).

Making these steps configurable could be a viable way forward I believe.

Best regards,
Andreas

________________________________________

Andreas Hedstr?m Mace
Systems Librarian
Stockholm University Library
Stockholm University
106 91 Stockholm
Tel: +46 (0) 8-16 49 17
su.se/english/library/

________________________________________




Fr?n: <mailto:koha-devel-bounces at lists.koha-community.org> p? uppdrag av David Cook <mailto:dcook at prosentient.com.au>
Datum: fredag 30 november 2018 00:36
Till: 'Holger Meissner' <mailto:Holger.Meissner at hs-gesundheit.de>, "mailto:koha-devel at lists.koha-community.org" <mailto:koha-devel at lists.koha-community.org>
?mne: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

Thanks for your feedback, Holger. 
 
Do you currently use autorenewals? I think you might be misunderstanding how it works?
 
The precedence of ?on hold > too many > too soon? is illogical for autorenewal in my mind. When the autorenewal daily cronjob runs, it will only send email alerts for ?too many? and ?on hold?. The most common outcome of the script should be ?too soon? as it?s during the normal loan period before the due date, so it really should be the first check. If it?s not ?too soon?, then you try to process a renewal. The next step would be checking if you have any renewals left. If not, then it?s ?too many?. If you do have renewals left, then you move to the next check, which would be checking for holds. The logical precedence would be ?too soon > too many > on hold?. 
 
?A patron might decide to return that book earlier if they know someone else is waiting instead of just knowing that it won?t be renewed anymore?. That seems to be a corruption/bleeding of scope for an autorenewal script. If you want to notify patrons when someone places a hold on their loan so that they can decide to return it out of courtesy, I?d recommend making adding a different feature for that (and probably integrate it with recalls which could optionally shorten the due date of the on loan item so the patron has to return it earlier for the person who put the hold on it ? recalls is a common feature in other established ILS/LMS systems). 
 
?And knowing that the book won?t be renewed anymore is more useful information than just knowing that it?s too early right now?. Firstly, they don?t currently know that it?s too early, as email notifications don?t go out for ?too soon?. Secondly, I have patrons returning their books when they get the ?can?t autorenew because there is a hold?, because they think that their book has been recalled even though Koha thinks they actually have several weeks left, because their loan was in fact successfully autorenewed the day before they got the ?on hold? email notification. 
 
At this point, librarians are getting annoyed at Koha for misleading patrons, and I?m advising librarians to not use the autorenewal function as a result. 
 
My options are as follows:
1) Continue warning people that this feature doesn?t work as they expect, which doesn?t look good for Koha
2) Patch the script via the Koha community workflow, which is ideal for developers and librarians
3) Patch the script locally, which is far from ideal, but will make librarians happy
 
I?ve been extremely busy, but it is my intention to submit a patch for this. If there is enough disagreement about the order of steps, perhaps it would be best to make the order of steps configurable. It wouldn?t be a difficult thing to do. 
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
From: mailto:koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Holger Meissner
Sent: Friday, 30 November 2018 1:29 AM
To: mailto:koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Thanks for the explanation, David.
 
> Yes, I would like to get the ?too soon? error message instead of the ?on reserve? error message if both apply.
 
I?d rather not. If patrons only know it?s too early they will expect a renewal. Which won?t happen, because of the hold we already know about. Why not tell them right away?
I would agree if holds were canceled most of the time, but in my estimate they aren?t.
 
> Koha shouldn?t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item?s status is on loan.
 
How would you implement something like that? The autorenew cronjob can?t do nothing. It has to try and renew everything every time it runs.
 
> In other words, autorenewal should be treated the exact same as manual 
> renewal. If Person A manually renews Book A on September 1
> 2018 making a new due date of September 15 2018 and Person B puts a 
> hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can?t renew because of a hold.
 
I believe they are treated equally, i.e. nothing prevents Person A from manually trying to renew again on September 2. And in that case they will see the hold.
 
> Currently, people are getting emails telling them they can?t autorenew 
> their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical.
 
I?m probably missing something but I don?t see what?s illogical or misleading about it.
 
I think on hold > too many > too early is good precedence, because of the information they give. A patron might decide to return that book earlier if they know someone else is waiting, instead of just knowing that it won?t be renewed anymore. And knowing that the book won?t be renewed anymore is more useful information than just knowing that it?s too early right now, even if all three apply at the same time.
 
Regards,
Holger
 
Von: David Cook <mailto:dcook at prosentient.com.au>
Gesendet: Mittwoch, 28. November 2018 01:24
An: Holger Meissner <mailto:Holger.Meissner at hs-gesundheit.de>; mailto:koha-devel at lists.koha-community.org
Betreff: RE: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi Holger,
 
Nope, I don?t want to change autorenewal being stopped when a hold is placed. 
 
Yes, I would like to get the ?too soon? error message instead of the ?on reserve? error message if both apply. 
 
Here?s my reasoning:
 
1) Book A is due on September 1 2018
2) Book A is autorenewed until September 15 2018
3) Person B places a hold on Book A
4) Koha shouldn?t do anything until the threshold for autorenewal (e.g. September 15 2018), because the item?s status is on loan. 
 
In other words, autorenewal should be treated the exact same as manual renewal. If Person A manually renews Book A on September 1 2018 making a new due date of September 15 2018 and Person B puts a hold on Book A on September 2 2018, nothing would happen until Person A tried to manually renew Book A on September 15 2018. At that point, Koha would say they can?t renew because of a hold. 
 
Currently, people are getting emails telling them they can?t autorenew their book on September 2 2018 because someone has placed a hold, but this is a misleading email, because on September 1 2018 their book was autorenewed until September 15 2018. The email is illogical. 
 
It shouldn?t be trying to autorenew because it?s ?too soon?. Only when it?s otherwise renewable should we be checking for holds. 
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
From: Holger Meissner [mailto:Holger.Meissner at hs-gesundheit.de]
Sent: Wednesday, 28 November 2018 4:37 AM
To: David Cook <mailto:dcook at prosentient.com.au>; mailto:koha-devel at lists.koha-community.org
Subject: AW: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi David,
 
could you expand on this? It?s intentional that autorenewal stops when a hold is placed. Do you want to change this behaviour?
 
Or would you like to get the ?too soon? error message instead of the ?on reserve? error message if both apply? Or a new message informing you about both?
 
What?s the benefit of checking whether it?s too early first?
 
Regards,
Holger
 
 
Von: mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> Im Auftrag von David Cook
Gesendet: Freitag, 16. November 2018 05:58
An: mailto:koha-devel at lists.koha-community.org
Betreff: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day
 
Hi all,
 
I?ve found a case where autorenewals will renew an item one day (e.g. Monday) and the next day (e.g. Tuesday) it will say that a hold has been found and that it can?t renew the item. (Someone must?ve put a hold on the item between the two cronjob runs.)
 
It seems to me this is a bug in how C4::Circulation::CanBookBeRenewed is written. 
 
The first check it makes is for holds and if it finds a hold it returns an error. 
 
However, if you?re using autorenewals, you should first check to see if it?s too early to even bother renewing. 
 
I?m just emailing here to see if anyone else is having this issue, or if anyone knows if there is already a Bugzilla issue open for it. It seems like there are a lot of autorenewal Bugzilla issues but I couldn?t find anything. Figure asking first lessens the need for someone to mark one as a duplicate later.
 
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
 
Office: 02 9212 0899
Direct: 02 8005 0595
 
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/



From ere.maijala at helsinki.fi  Mon Dec 10 08:17:49 2018
From: ere.maijala at helsinki.fi (Ere Maijala)
Date: Mon, 10 Dec 2018 09:17:49 +0200
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
	<467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
Message-ID: <f37ac60c-7c7b-755c-0266-67a22a5abf3c@helsinki.fi>

For the record, I mixed the internal memory cache with Cache::Memory,
so... +1 for removal of Cache::Memory.

--Ere

Ere Maijala kirjoitti 7.12.2018 klo 9.55:
> I'm a bit hesitant on this. I understand running without a cache makes
> things like tests easier, but Cache::Memory is actually a pretty useful
> fallback. There's a lot of code in Koha that does redundant fetches of
> e.g. framework data, and without caching I'm afraid it will slow down
> significantly. Cache::Memory is very handy when developing stuff to
> speed up execution of e.g. batch utilities when you don't want to mess
> with constantly flushing Memcached.
> 
> I would like to propose another approach for considerarion: disable
> Cache::Memory only if running under Plack.
> 
> --Ere
> 
> David Cook kirjoitti 7.12.2018 klo 1.52:
>> I?ve noticed some caching issues but haven?t had time to investigate too
>> deeply. I wonder if this relates to what I?ve encountered.
>>
>> ?
>>
>> In any case, +1!
>>
>> ?
>>
>> David Cook
>>
>> Systems Librarian
>>
>> Prosentient Systems
>>
>> 72/330 Wattle St
>>
>> Ultimo, NSW 2007
>>
>> Australia
>>
>> ?
>>
>> Office: 02 9212 0899
>>
>> Direct: 02 8005 0595
>>
>> ?
>>
>> *From:*koha-devel-bounces at lists.koha-community.org
>> [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
>> *Tomas Cohen Arazi
>> *Sent:* Friday, 7 December 2018 2:44 AM
>> *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
>> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
>> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
>>
>> ?
>>
>> Get rid of it!
>>
>> ?
>>
>> +1
>>
>> ?
>>
>> El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
>> (<jonathan.druart at bugs.koha-community.org
>> <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
>>
>>     Hi devs,
>>
>>     I am still recovering from my holidays and I think I caught a quite
>>     big fish.
>>
>>     After an interesting track game I will explain why I am suggesting to
>>     remove Cache::Memory that is currently used as fallback for the L2
>>     cache.
>>
>>     What I tried to fix:
>>     Jenkins is complaining about selenium tests (regressions.t) failing on
>>     18.05, it is a succession of events and bugs that were not linked at
>>     first glance.
>>
>>     Here are the different steps I went though:
>>     - On bug 21426 we noticed that USE_MEMCACHED was not taken into
>>     account. If set to "no" the default memcached config was defined in
>>     the koha-config.xml file anyway
>>     - A new regression selenium test was added on bug 21777 to catch the
>>     presence of an audio alert on the circulation page
>>     - Investigating the failing tests I noticed that koha-testing-docker
>>     was not setting the memcached config on the 18.05 branches (I guess
>>     the image has not been rebuilt yet)
>>     search_utf8.t output "Warning: script running in daemon mode, without
>>     recommended caching system (memcached)."
>>     - I also find that [% Koha.Preference('AudioAlerts') %] did not return
>>     the value set by the tests, but the value that the DB has before the
>>     tests were launched
>>     => It is a cache issue!
>>     - ...but only when memcached is not set...
>>     - Reading Koha::Cache->new we can notice that Cache::Memory is used
>>     for the L2 cache when memcached is not defined in the config
>>
>>     And so we have the problem: If a value is set in the cache by a Plack
>>     worker, it will not be available from another one, as the L2 cache is
>>     not shared (!)
>>
>>     To recreate easily the problem you can:
>>     - remove the memcached config
>>     - edit intranet-bottom.inc and add
>>     ===[% Koha.Preference('AudioAlerts') %]===
>>     - restart plack
>>     - Modify the value of AudioAlerts (using the UI)
>>     - Reload the page (reload several times if the value is still correct,
>>     it will depend on which worker will serve the request)
>>
>>     Solution:
>>     I am considering removing Cache::Memory unless somebody else has a
>>     better idea
>>     Bug 21955 - Cache::Memory should not be used as L2 cache
>>
>>     Note that it should not affect a lot of people as everybody is
>>     supposed to have memcached configured and working correctly!
>>
>>     Cheers,
>>     Jonathan
>>     _______________________________________________
>>     Koha-devel mailing list
>>     Koha-devel at lists.koha-community.org
>>     <mailto:Koha-devel at 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/
>>
>>
>> ?
>>
>> -- 
>>
>> Tom?s Cohen Arazi
>>
>> Theke Solutions (http://theke.io <http://theke.io/>)
>> ?+54 9351 3513384
>> GPG: B2F3C15F
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
> 

-- 
Ere Maijala
Kansalliskirjasto / The National Library of Finland


From Holger.Meissner at hs-gesundheit.de  Mon Dec 10 17:47:19 2018
From: Holger.Meissner at hs-gesundheit.de (Holger Meissner)
Date: Mon, 10 Dec 2018 16:47:19 +0000
Subject: [Koha-devel] Autorenewals renewing an item then sending a renew
 failure email the next day
In-Reply-To: <CAHGWiG6RgXYsOzL+hwhh8F9zwCQDdn7-GvgiRvAnSxbU+0p0bQ@mail.gmail.com>
References: <cd765a54d0de44e887cf719b4fc72ed8@nExchange2.hsg.intra>
	<CAK6s+rV7WTUvh9k1FmHy7MXB13HaEhbCnUsM58cQt-MoN3n2wA@mail.gmail.com>
	<CAHGWiG6RgXYsOzL+hwhh8F9zwCQDdn7-GvgiRvAnSxbU+0p0bQ@mail.gmail.com>
Message-ID: <344c9c7da48f469781a743c54c093c7f@nExchange2.hsg.intra>

On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:janet.mcgowan at ptfs-europe.com> wrote:
> Our feedback from customers has been that the user only needs to be informed that the autorenewal
> cannot take place at the point that the renewal would take place (ie at the point that the No renewal
> before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before?

We actually use OPACUserJS to hide that setting.

Regards,
Holger

From janet.mcgowan at ptfs-europe.com  Mon Dec 10 18:02:26 2018
From: janet.mcgowan at ptfs-europe.com (McGowan, Janet)
Date: Mon, 10 Dec 2018 17:02:26 +0000
Subject: [Koha-devel] Autorenewals renewing an item then sending a renew
 failure email the next day
In-Reply-To: <344c9c7da48f469781a743c54c093c7f@nExchange2.hsg.intra>
References: <cd765a54d0de44e887cf719b4fc72ed8@nExchange2.hsg.intra>
	<CAK6s+rV7WTUvh9k1FmHy7MXB13HaEhbCnUsM58cQt-MoN3n2wA@mail.gmail.com>
	<CAHGWiG6RgXYsOzL+hwhh8F9zwCQDdn7-GvgiRvAnSxbU+0p0bQ@mail.gmail.com>
	<344c9c7da48f469781a743c54c093c7f@nExchange2.hsg.intra>
Message-ID: <CAK6s+rW7ijUHNhnSuqF8iEHjapwPKDYjg+8jZ=wiSFAW+-As0Q@mail.gmail.com>

Yes, using the PREDUE notice is a way around this, however it would only
work if No renewal before is set to 1.
Having said that there are many benefits to the --send-notice functionality
- the end user is notified about the reason why a material is renewed or
otherwise - so ideally we would like to be able to use this separate
autorenewal notification.
I believe the community bug for this is
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014
but in a few brief tests I don't believe it totally fixes the problem, I'm
afraid I haven't had a chance to test the fix properly yet though.
-Janet



*Janet McGowan*

<https://www.ptfs-europe.com/>

Director of Operations





*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7985 431 266

*Email:* janet.mcgowan at ptfs-europe.com

www.ptfs-europe.com







Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com


On Mon, 10 Dec 2018 at 16:47, Holger Meissner <
Holger.Meissner at hs-gesundheit.de> wrote:

> On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:
> janet.mcgowan at ptfs-europe.com> wrote:
> > Our feedback from customers has been that the user only needs to be
> informed that the autorenewal
> > cannot take place at the point that the renewal would take place (ie at
> the point that the No renewal
> > before policy values kicks in).
>
> I wonder if the regular PREDUE notice is sufficient for that or not? Maybe
> we don't need a special auto renewal notice, but rather a way to make sure
> that the PREDUE trigger can't be set to any value > no renewal before?
>
> We actually use OPACUserJS to hide that setting.
>
> Regards,
> Holger
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181210/5f3a85cc/attachment.html>

From dcook at prosentient.com.au  Tue Dec 11 04:38:41 2018
From: dcook at prosentient.com.au (David Cook)
Date: Tue, 11 Dec 2018 14:38:41 +1100
Subject: [Koha-devel] Autorenewals renewing an item then sending a renew
	failure email the next day
In-Reply-To: <CAK6s+rW7ijUHNhnSuqF8iEHjapwPKDYjg+8jZ=wiSFAW+-As0Q@mail.gmail.com>
References: <cd765a54d0de44e887cf719b4fc72ed8@nExchange2.hsg.intra>	<CAK6s+rV7WTUvh9k1FmHy7MXB13HaEhbCnUsM58cQt-MoN3n2wA@mail.gmail.com>	<CAHGWiG6RgXYsOzL+hwhh8F9zwCQDdn7-GvgiRvAnSxbU+0p0bQ@mail.gmail.com>	<344c9c7da48f469781a743c54c093c7f@nExchange2.hsg.intra>
	<CAK6s+rW7ijUHNhnSuqF8iEHjapwPKDYjg+8jZ=wiSFAW+-As0Q@mail.gmail.com>
Message-ID: <01ce01d49103$0262dd30$07289790$@prosentient.com.au>

It looks like the libraries I support don?t want to turn off the notices (by removing --send-notice) but they also don?t want to have the behaviour of getting emails saying the item can?t be renewed because of a hold when it?s still too soon. 

 

So we need to work something out. 

 

I have other priorities at the moment that need my attention, but let?s see if I can write something quickly?

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of McGowan, Janet
Sent: Tuesday, 11 December 2018 4:02 AM
To: Holger.Meissner at hs-gesundheit.de
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1. 

Having said that there are many benefits to the --send-notice functionality - the end user is notified about the reason why a material is renewed or otherwise - so ideally we would like to be able to use this separate autorenewal notification.

I believe the community bug for this is https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 

but in a few brief tests I don't believe it totally fixes the problem, I'm afraid I haven't had a chance to test the fix properly yet though.

-Janet


 


Janet McGowan

 <https://www.ptfs-europe.com/> 


Director of Operations


 


 


Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7985 431 266


Email:  <mailto:janet.mcgowan at ptfs-europe.com> janet.mcgowan at ptfs-europe.com

 <https://www.ptfs-europe.com/> www.ptfs-europe.com


 

	

 

	

 

	

 


Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

 

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com <mailto:info at ptfs-europe.com> 

 

 

On Mon, 10 Dec 2018 at 16:47, Holger Meissner <Holger.Meissner at hs-gesundheit.de <mailto:Holger.Meissner at hs-gesundheit.de> > wrote:

On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:janet.mcgowan at ptfs-europe.com <mailto:janet.mcgowan at ptfs-europe.com> > wrote:
> Our feedback from customers has been that the user only needs to be informed that the autorenewal
> cannot take place at the point that the renewal would take place (ie at the point that the No renewal
> before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before?

We actually use OPACUserJS to hide that setting.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181211/7194dbe7/attachment-0001.html>

From dcook at prosentient.com.au  Tue Dec 11 05:02:25 2018
From: dcook at prosentient.com.au (David Cook)
Date: Tue, 11 Dec 2018 15:02:25 +1100
Subject: [Koha-devel] Autorenewals renewing an item then sending a renew
	failure email the next day
In-Reply-To: <CAK6s+rW7ijUHNhnSuqF8iEHjapwPKDYjg+8jZ=wiSFAW+-As0Q@mail.gmail.com>
References: <cd765a54d0de44e887cf719b4fc72ed8@nExchange2.hsg.intra>	<CAK6s+rV7WTUvh9k1FmHy7MXB13HaEhbCnUsM58cQt-MoN3n2wA@mail.gmail.com>	<CAHGWiG6RgXYsOzL+hwhh8F9zwCQDdn7-GvgiRvAnSxbU+0p0bQ@mail.gmail.com>	<344c9c7da48f469781a743c54c093c7f@nExchange2.hsg.intra>
	<CAK6s+rW7ijUHNhnSuqF8iEHjapwPKDYjg+8jZ=wiSFAW+-As0Q@mail.gmail.com>
Message-ID: <01da01d49106$53618bc0$fa24a340$@prosentient.com.au>

I?ve taken another look at C4::Circulation::CanBookBeRenewed(), and it seems that function could benefit from functional decomposition. The function is about 180 lines which seem too fragile to touch. 

 

Jonathan has posted a patch to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 but there seems to be a fair amount of disagreement with its approach to solving the problem. 

 

That said, without refactoring C4::Circulation::CanBookBeRenewed(), changing ./misc/cronjobs/automatic_renewals.pl seems like the only way forward. 

 

But changing ./misc/cronjobs/automatic_renewals.pl means making too many assumptions about what to do. 

 

I don?t see a practical way forward without refactoring C4::Circulation::CanBookBeRenewed(), but it?s such an important and multi-factor part of Koha that I?m reluctant to touch it. There do seem to be a fair number of tests in t/db_dependent/Circulation.t but I don?t think I can commit the time/effort to this issue at the moment. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of McGowan, Janet
Sent: Tuesday, 11 December 2018 4:02 AM
To: Holger.Meissner at hs-gesundheit.de
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day

 

Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1. 

Having said that there are many benefits to the --send-notice functionality - the end user is notified about the reason why a material is renewed or otherwise - so ideally we would like to be able to use this separate autorenewal notification.

I believe the community bug for this is https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19014 

but in a few brief tests I don't believe it totally fixes the problem, I'm afraid I haven't had a chance to test the fix properly yet though.

-Janet


 


Janet McGowan

 <https://www.ptfs-europe.com/> 


Director of Operations


 


 


Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7985 431 266


Email:  <mailto:janet.mcgowan at ptfs-europe.com> janet.mcgowan at ptfs-europe.com

 <https://www.ptfs-europe.com/> www.ptfs-europe.com


 

	

 

	

 

	

 


Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

 

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com <mailto:info at ptfs-europe.com> 

 

 

On Mon, 10 Dec 2018 at 16:47, Holger Meissner <Holger.Meissner at hs-gesundheit.de <mailto:Holger.Meissner at hs-gesundheit.de> > wrote:

On Mon, Dec 10, 2018 at 10:56 AM McGowan, Janet <mailto:janet.mcgowan at ptfs-europe.com <mailto:janet.mcgowan at ptfs-europe.com> > wrote:
> Our feedback from customers has been that the user only needs to be informed that the autorenewal
> cannot take place at the point that the renewal would take place (ie at the point that the No renewal
> before policy values kicks in).

I wonder if the regular PREDUE notice is sufficient for that or not? Maybe we don't need a special auto renewal notice, but rather a way to make sure that the PREDUE trigger can't be set to any value > no renewal before?

We actually use OPACUserJS to hide that setting.

Regards,
Holger
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181211/691c8386/attachment.html>

From Holger.Meissner at hs-gesundheit.de  Tue Dec 11 11:29:49 2018
From: Holger.Meissner at hs-gesundheit.de (Holger Meissner)
Date: Tue, 11 Dec 2018 10:29:49 +0000
Subject: [Koha-devel] Autorenewals renewing an item then sending a renew
 failure email the next day
In-Reply-To: <CAK6s+rW7ijUHNhnSuqF8iEHjapwPKDYjg+8jZ=wiSFAW+-As0Q@mail.gmail.com>
References: <cd765a54d0de44e887cf719b4fc72ed8@nExchange2.hsg.intra>
	<CAK6s+rV7WTUvh9k1FmHy7MXB13HaEhbCnUsM58cQt-MoN3n2wA@mail.gmail.com>
	<CAHGWiG6RgXYsOzL+hwhh8F9zwCQDdn7-GvgiRvAnSxbU+0p0bQ@mail.gmail.com>
	<344c9c7da48f469781a743c54c093c7f@nExchange2.hsg.intra>
	<CAK6s+rW7ijUHNhnSuqF8iEHjapwPKDYjg+8jZ=wiSFAW+-As0Q@mail.gmail.com>
Message-ID: <9f02d5c8cbb64c31b50136ea4ba1a7fb@nExchange2.hsg.intra>

On Mon, Dec 10, 2018 at 06:02 PM McGowan, Janet <mailto:mailto:janet.mcgowan at ptfs-europe.com> wrote:
> Yes, using the PREDUE notice is a way around this, however it would only work if No renewal before is set to 1.?

I disagree. For example, we set "no renewal before" to 11 days and send PREDUE 10 days in advance. We locally prevent patrons from changing that setting. Nobody complained about it so far. A more elegant and more user-friendly solution would be a feature enforcing PREDUE <= no renewal before. Or maybe just a warning popup for spam producing values.

Regards,
Holger

From arouss1980 at gmail.com  Wed Dec 12 10:42:29 2018
From: arouss1980 at gmail.com (Andreas Roussos)
Date: Wed, 12 Dec 2018 11:42:29 +0200
Subject: [Koha-devel] Cover image 'thumbnail' size is bigger than
	'imagefile' size
Message-ID: <CAK0RUruvgOF_bk=edasM3dpAswrvx2HqVsHMP0Q2Bx4uUbD63Q@mail.gmail.com>

Dear Developers,

We use local cover images in our setup, and also resize the covers
we scan to a width of 160px before uploading and attaching them to
a Koha bibliographic record (we upload one cover per biblio).

While using phpMyAdmin to view the contents of the 'biblioimages'
table (relevant screenshot here: https://imgur.com/a/cSEVLBI), we
noticed that the size of the BLOBs for the 'thumbnail' column was in
some cases twice as big as that of the 'imagefile' column. In fact,
this happens for more than 50% of uploaded covers as you can see
from the output of the SQL queries below:

mysql> SELECT COUNT( * ) AS count
         FROM biblioimages
        WHERE LENGTH( thumbnail ) > ( LENGTH( imagefile ) * 2 ) ;
+-------+
| count |
+-------+
|  1356 |
+-------+

mysql> SELECT COUNT( * ) AS count,
              SUM( LENGTH( imagefile ) ) AS images_size,
              SUM( LENGTH( thumbnail ) ) AS thumbnails_size
         FROM biblioimages ;
+-------+-------------+-----------------+
| count | images_size | thumbnails_size |
+-------+-------------+-----------------+
|  2347 |    68323933 |       115839686 |
+-------+-------------+-----------------+

It would appear that for each 160px-wide JPG with 24-bit depth that
we have uploaded, the 'imagefile' column has been populated with an
PNG of 8 bit depth with the same dimensions as the uploaded file,
whereas the 'thumbnail' column contains a 24-bit PNG image with a
width reduced to 140 pixels.

I've tracked down the creation of resized 24-bit PNGs to this code:
https://github.com/Koha-Community/Koha/blob/master/C4/Images.pm#L182-L183

Do thumbnails for covers need to be true colour (24-bit) images?

Also, why is it that _scale_image() returns an image of 8-bit depth
if the source image's dimensions are less than 600x800? (i.e. when
no resizing is performed)

Thank you in advance for your time.

Kind regards,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181212/082294af/attachment.html>

From jonathan.druart at bugs.koha-community.org  Wed Dec 12 13:49:36 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 12 Dec 2018 09:49:36 -0300
Subject: [Koha-devel] Cover image 'thumbnail' size is bigger than
 'imagefile' size
In-Reply-To: <CAK0RUruvgOF_bk=edasM3dpAswrvx2HqVsHMP0Q2Bx4uUbD63Q@mail.gmail.com>
References: <CAK0RUruvgOF_bk=edasM3dpAswrvx2HqVsHMP0Q2Bx4uUbD63Q@mail.gmail.com>
Message-ID: <CAJzKNY5gF_4UybC743t_S3EumD7924TaPh6x3F81reaA4P-CAA@mail.gmail.com>

Hi Andreas,

This module has never been enhanced much and as you noticed there is
room for such enhancements :)
All of what you describe in your email makes sense to me, and I am
sure the changes will be accepted if a patch is provided.

Cheers,
Jonathan
Le mer. 12 d?c. 2018 ? 06:42, Andreas Roussos <arouss1980 at gmail.com> a ?crit :
>
> Dear Developers,
>
> We use local cover images in our setup, and also resize the covers
> we scan to a width of 160px before uploading and attaching them to
> a Koha bibliographic record (we upload one cover per biblio).
>
> While using phpMyAdmin to view the contents of the 'biblioimages'
> table (relevant screenshot here: https://imgur.com/a/cSEVLBI), we
> noticed that the size of the BLOBs for the 'thumbnail' column was in
> some cases twice as big as that of the 'imagefile' column. In fact,
> this happens for more than 50% of uploaded covers as you can see
> from the output of the SQL queries below:
>
> mysql> SELECT COUNT( * ) AS count
>          FROM biblioimages
>         WHERE LENGTH( thumbnail ) > ( LENGTH( imagefile ) * 2 ) ;
> +-------+
> | count |
> +-------+
> |  1356 |
> +-------+
>
> mysql> SELECT COUNT( * ) AS count,
>               SUM( LENGTH( imagefile ) ) AS images_size,
>               SUM( LENGTH( thumbnail ) ) AS thumbnails_size
>          FROM biblioimages ;
> +-------+-------------+-----------------+
> | count | images_size | thumbnails_size |
> +-------+-------------+-----------------+
> |  2347 |    68323933 |       115839686 |
> +-------+-------------+-----------------+
>
> It would appear that for each 160px-wide JPG with 24-bit depth that
> we have uploaded, the 'imagefile' column has been populated with an
> PNG of 8 bit depth with the same dimensions as the uploaded file,
> whereas the 'thumbnail' column contains a 24-bit PNG image with a
> width reduced to 140 pixels.
>
> I've tracked down the creation of resized 24-bit PNGs to this code:
> https://github.com/Koha-Community/Koha/blob/master/C4/Images.pm#L182-L183
>
> Do thumbnails for covers need to be true colour (24-bit) images?
>
> Also, why is it that _scale_image() returns an image of 8-bit depth
> if the source image's dimensions are less than 600x800? (i.e. when
> no resizing is performed)
>
> Thank you in advance for your time.
>
> Kind regards,
> Andreas
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From paul.poulain at biblibre.com  Wed Dec 12 13:53:48 2018
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 12 Dec 2018 13:53:48 +0100
Subject: [Koha-devel] Cover image 'thumbnail' size is bigger than
 'imagefile' size
In-Reply-To: <CAJzKNY5gF_4UybC743t_S3EumD7924TaPh6x3F81reaA4P-CAA@mail.gmail.com>
References: <CAK0RUruvgOF_bk=edasM3dpAswrvx2HqVsHMP0Q2Bx4uUbD63Q@mail.gmail.com>
	<CAJzKNY5gF_4UybC743t_S3EumD7924TaPh6x3F81reaA4P-CAA@mail.gmail.com>
Message-ID: <3395dca6-b8cb-d420-bce3-cf605f6d97ca@biblibre.com>

Hi Andreas,

(and if you can't provide a patch, please file a bug on buzilla, this 
description is perfect ! )

Le 12/12/2018 ? 13:49, Jonathan Druart a ?crit?:
> Hi Andreas,
>
> This module has never been enhanced much and as you noticed there is
> room for such enhancements :)
> All of what you describe in your email makes sense to me, and I am
> sure the changes will be accepted if a patch is provided.
>
> Cheers,
> Jonathan
> Le mer. 12 d?c. 2018 ? 06:42, Andreas Roussos <arouss1980 at gmail.com> a ?crit :
>> Dear Developers,
>>
>> We use local cover images in our setup, and also resize the covers
>> we scan to a width of 160px before uploading and attaching them to
>> a Koha bibliographic record (we upload one cover per biblio).
>>
>> While using phpMyAdmin to view the contents of the 'biblioimages'
>> table (relevant screenshot here: https://imgur.com/a/cSEVLBI), we
>> noticed that the size of the BLOBs for the 'thumbnail' column was in
>> some cases twice as big as that of the 'imagefile' column. In fact,
>> this happens for more than 50% of uploaded covers as you can see
>> from the output of the SQL queries below:
>>
>> mysql> SELECT COUNT( * ) AS count
>>           FROM biblioimages
>>          WHERE LENGTH( thumbnail ) > ( LENGTH( imagefile ) * 2 ) ;
>> +-------+
>> | count |
>> +-------+
>> |  1356 |
>> +-------+
>>
>> mysql> SELECT COUNT( * ) AS count,
>>                SUM( LENGTH( imagefile ) ) AS images_size,
>>                SUM( LENGTH( thumbnail ) ) AS thumbnails_size
>>           FROM biblioimages ;
>> +-------+-------------+-----------------+
>> | count | images_size | thumbnails_size |
>> +-------+-------------+-----------------+
>> |  2347 |    68323933 |       115839686 |
>> +-------+-------------+-----------------+
>>
>> It would appear that for each 160px-wide JPG with 24-bit depth that
>> we have uploaded, the 'imagefile' column has been populated with an
>> PNG of 8 bit depth with the same dimensions as the uploaded file,
>> whereas the 'thumbnail' column contains a 24-bit PNG image with a
>> width reduced to 140 pixels.
>>
>> I've tracked down the creation of resized 24-bit PNGs to this code:
>> https://github.com/Koha-Community/Koha/blob/master/C4/Images.pm#L182-L183
>>
>> Do thumbnails for covers need to be true colour (24-bit) images?
>>
>> Also, why is it that _scale_image() returns an image of 8-bit depth
>> if the source image's dimensions are less than 600x800? (i.e. when
>> no resizing is performed)
>>
>> Thank you in advance for your time.
>>
>> Kind regards,
>> Andreas
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries


From arouss1980 at gmail.com  Wed Dec 12 15:49:16 2018
From: arouss1980 at gmail.com (Andreas Roussos)
Date: Wed, 12 Dec 2018 16:49:16 +0200
Subject: [Koha-devel] Cover image 'thumbnail' size is bigger than
 'imagefile' size
In-Reply-To: <3395dca6-b8cb-d420-bce3-cf605f6d97ca@biblibre.com>
References: <CAK0RUruvgOF_bk=edasM3dpAswrvx2HqVsHMP0Q2Bx4uUbD63Q@mail.gmail.com>
	<CAJzKNY5gF_4UybC743t_S3EumD7924TaPh6x3F81reaA4P-CAA@mail.gmail.com>
	<3395dca6-b8cb-d420-bce3-cf605f6d97ca@biblibre.com>
Message-ID: <CAK0RUru40DsVVp1ED=hkMJvfnfjpWrH9bdPSoLT5iipY5fbynQ@mail.gmail.com>

Hi Paul, Jonathan,

Thank you both for your prompt replies and your feedback.
I have now opened a new bug report here:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21987

Andreas

On Wed, 12 Dec 2018 at 14:53, Paul Poulain <paul.poulain at biblibre.com>
wrote:

> Hi Andreas,
>
> (and if you can't provide a patch, please file a bug on buzilla, this
> description is perfect ! )
>
> Le 12/12/2018 ? 13:49, Jonathan Druart a ?crit :
> > Hi Andreas,
> >
> > This module has never been enhanced much and as you noticed there is
> > room for such enhancements :)
> > All of what you describe in your email makes sense to me, and I am
> > sure the changes will be accepted if a patch is provided.
> >
> > Cheers,
> > Jonathan
> > Le mer. 12 d?c. 2018 ? 06:42, Andreas Roussos <arouss1980 at gmail.com> a
> ?crit :
> >> Dear Developers,
> >>
> >> We use local cover images in our setup, and also resize the covers
> >> we scan to a width of 160px before uploading and attaching them to
> >> a Koha bibliographic record (we upload one cover per biblio).
> >>
> >> While using phpMyAdmin to view the contents of the 'biblioimages'
> >> table (relevant screenshot here: https://imgur.com/a/cSEVLBI), we
> >> noticed that the size of the BLOBs for the 'thumbnail' column was in
> >> some cases twice as big as that of the 'imagefile' column. In fact,
> >> this happens for more than 50% of uploaded covers as you can see
> >> from the output of the SQL queries below:
> >>
> >> mysql> SELECT COUNT( * ) AS count
> >>           FROM biblioimages
> >>          WHERE LENGTH( thumbnail ) > ( LENGTH( imagefile ) * 2 ) ;
> >> +-------+
> >> | count |
> >> +-------+
> >> |  1356 |
> >> +-------+
> >>
> >> mysql> SELECT COUNT( * ) AS count,
> >>                SUM( LENGTH( imagefile ) ) AS images_size,
> >>                SUM( LENGTH( thumbnail ) ) AS thumbnails_size
> >>           FROM biblioimages ;
> >> +-------+-------------+-----------------+
> >> | count | images_size | thumbnails_size |
> >> +-------+-------------+-----------------+
> >> |  2347 |    68323933 |       115839686 |
> >> +-------+-------------+-----------------+
> >>
> >> It would appear that for each 160px-wide JPG with 24-bit depth that
> >> we have uploaded, the 'imagefile' column has been populated with an
> >> PNG of 8 bit depth with the same dimensions as the uploaded file,
> >> whereas the 'thumbnail' column contains a 24-bit PNG image with a
> >> width reduced to 140 pixels.
> >>
> >> I've tracked down the creation of resized 24-bit PNGs to this code:
> >>
> https://github.com/Koha-Community/Koha/blob/master/C4/Images.pm#L182-L183
> >>
> >> Do thumbnails for covers need to be true colour (24-bit) images?
> >>
> >> Also, why is it that _scale_image() returns an image of 8-bit depth
> >> if the source image's dimensions are less than 600x800? (i.e. when
> >> no resizing is performed)
> >>
> >> Thank you in advance for your time.
> >>
> >> Kind regards,
> >> Andreas
> >> _______________________________________________
> >> Koha-devel mailing list
> >> Koha-devel at 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/
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
>
> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181212/d6ec7e32/attachment.html>

From jonathan.druart at bugs.koha-community.org  Wed Dec 12 18:32:57 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Wed, 12 Dec 2018 14:32:57 -0300
Subject: [Koha-devel] Missing FK on serial tables (?)
Message-ID: <CAJzKNY5cyW9Lg+LeRN_DpWhbbHF3DRka4JzsvUBOONpV45NoGw@mail.gmail.com>

Hi devs,

A quick question, in case I am missing something obvious.
Reported on bug 21901: indices are missing on the serial and
subscription tables.

Worst is, in the serial table:
  `biblionumber` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `subscriptionid` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',


So I think we should:
Add FK (with on delete cascade) on
- serial.biblionumber
- serial.subscritionid
- subscription.biblionumber

Would it make sense?

Cheers,
Jonathan

From katrin.fischer.83 at web.de  Thu Dec 13 13:29:27 2018
From: katrin.fischer.83 at web.de (Katrin Fischer)
Date: Thu, 13 Dec 2018 13:29:27 +0100
Subject: [Koha-devel] Missing FK on serial tables (?)
In-Reply-To: <CAJzKNY5cyW9Lg+LeRN_DpWhbbHF3DRka4JzsvUBOONpV45NoGw@mail.gmail.com>
References: <CAJzKNY5cyW9Lg+LeRN_DpWhbbHF3DRka4JzsvUBOONpV45NoGw@mail.gmail.com>
Message-ID: <f4fc53c0-eea5-f82b-f9e3-60b1268edee2@web.de>

Hi Jonathan,

I think it makes sense - there should be no serials and subscriptions 
without a linked bibliographic record. In addition to the delete case we 
should also make sure that it updates the biblionumber on changing the 
linking in the subscription or when merging records (on update 
cascade?). I think at the moment this doesn't work correctly and you end 
up with the wrong biblionumbers in serials (see also bugs 12921, 5334, 
21232).

Katrin

On 12.12.18 18:32, Jonathan Druart wrote:
> Hi devs,
>
> A quick question, in case I am missing something obvious.
> Reported on bug 21901: indices are missing on the serial and
> subscription tables.
>
> Worst is, in the serial table:
>    `biblionumber` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
>    `subscriptionid` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
>
>
> So I think we should:
> Add FK (with on delete cascade) on
> - serial.biblionumber
> - serial.subscritionid
> - subscription.biblionumber
>
> Would it make sense?
>
> Cheers,
> Jonathan
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From kohanews at gmail.com  Fri Dec 14 19:22:51 2018
From: kohanews at gmail.com (kohanews)
Date: Fri, 14 Dec 2018 10:22:51 -0800
Subject: [Koha-devel] Call for News: December 2018 Newsletter
Message-ID: <882e1d23-eddb-0a15-457d-b979f098217b@gmail.com>

I'm collecting news for the December newsletter. Send anything 
noteworthy to:

k o h a news AT gmail dot com

News criteria:
---------------------------

** For events **:
 ?? - Please include dates for past events. If I can't find dates I may 
not add it.
 ?? - Announcements for future events with dates T.B.A. are fine ...Eg., 
Kohacon
 ?? - For past events , **** one month back is the cut-off? ****.

* News items can be of any length.
* Images are fine
* Anything and everything Koha.
* Submit by the 26th of the month.

If you are working on an interesting project or development related to
Koha, please let me know and I'll include it in the development section.

Thank you!

-- 
Chad Roseburg
Editor, Koha Community Newsletter


From dcook at prosentient.com.au  Mon Dec 17 08:06:43 2018
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 17 Dec 2018 18:06:43 +1100
Subject: [Koha-devel] Low Zebra performance for persistent/re-used
	connections
Message-ID: <000801d495d7$10cf37f0$326da7d0$@prosentient.com.au>

Hi all,

 

I'm writing a custom script that uses C4::Context->Zconn to create a Zebra
connection and then I'm sending a bunch of queries. 

 

If I don't have the GATEWAY_INTERFACE environmental variable defined, that
method returns the same connection. (Note that I'm working with Unix sockets
and not TCP sockets.)

 

When re-using the same connection, my script uses 100% CPU. 

 

When using new connections for every request, my script uses 3% CPU.

 

When re-using the same connection, Zebra seems pretty fast for the first
1000-2000 queries (I didn't capture exact numbers), but performance degrades
rapidly. Around 3000 queries, Zebra is only processing about 4-6 queries per
second.  

 

When using new connections, Zebra is handling about 93 queries per second.

 

Zebra is forking a process for every connection, so it seems like the
overhead should be greater creating a new process for every request, but
performance is exponentially better when forcing new connections for each
request  than when re-using the connection.  

 

It looks like Zebra doesn't expect a single connection/worker process to
handle too many requests. Or maybe it's an issue with the ZOOM library. I
don't know. I don't know enough about the internals of either of them. 

 

So this could affect any command line tool that handles high volumes of
Zebra queries. While re-using connections makes sense in theory, it seems to
actually cause problems when talking to Zebra. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181217/894b2f9e/attachment.html>

From dcook at prosentient.com.au  Wed Dec 19 01:57:57 2018
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 19 Dec 2018 11:57:57 +1100
Subject: [Koha-devel] Low Zebra performance for persistent/re-used
	connections
Message-ID: <011101d49735$e180c300$a4824900$@prosentient.com.au>

And now I try again today with re-using the connection and the performance
is amazing and the CPU usage is much higher than 3% but nowhere near 100%.
Looks like I must've just been misusing the ZOOM library perhaps..

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: David Cook [mailto:dcook at prosentient.com.au] 
Sent: Monday, 17 December 2018 6:07 PM
To: 'koha-devel at lists.koha-community.org'
<koha-devel at lists.koha-community.org>
Subject: Low Zebra performance for persistent/re-used connections

 

Hi all,

 

I'm writing a custom script that uses C4::Context->Zconn to create a Zebra
connection and then I'm sending a bunch of queries. 

 

If I don't have the GATEWAY_INTERFACE environmental variable defined, that
method returns the same connection. (Note that I'm working with Unix sockets
and not TCP sockets.)

 

When re-using the same connection, my script uses 100% CPU. 

 

When using new connections for every request, my script uses 3% CPU.

 

When re-using the same connection, Zebra seems pretty fast for the first
1000-2000 queries (I didn't capture exact numbers), but performance degrades
rapidly. Around 3000 queries, Zebra is only processing about 4-6 queries per
second.  

 

When using new connections, Zebra is handling about 93 queries per second.

 

Zebra is forking a process for every connection, so it seems like the
overhead should be greater creating a new process for every request, but
performance is exponentially better when forcing new connections for each
request  than when re-using the connection.  

 

It looks like Zebra doesn't expect a single connection/worker process to
handle too many requests. Or maybe it's an issue with the ZOOM library. I
don't know. I don't know enough about the internals of either of them. 

 

So this could affect any command line tool that handles high volumes of
Zebra queries. While re-using connections makes sense in theory, it seems to
actually cause problems when talking to Zebra. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181219/45c30151/attachment.html>

From dcook at prosentient.com.au  Wed Dec 19 02:08:14 2018
From: dcook at prosentient.com.au (David Cook)
Date: Wed, 19 Dec 2018 12:08:14 +1100
Subject: [Koha-devel] Possible memory leak when using ZOOM libraries with
	Zebra
Message-ID: <011b01d49737$512bd6d0$f3838470$@prosentient.com.au>

Hi all,

 

I've been playing with the ZOOM libraries and Zebra, and it seems like
there's a memory leak when using C4::Context->Zconn with the environmental
variable GATEWAY_INTERFACE.

 

I had a script that was creating a new connection for each request, and
C4::Context->Zconn did look like it was calling the destroy method on the
connection before creating a new one, and it was clear that each request was
using a new connection, but I noticed the memory usage on the script slowly
started going up. For a long-running script, the memory usage got over a
gigabyte. 

 

If I re-use the connection (ie don't have GATEWAY_INTERFACE turned on),
there's no memory leak. 

 

It shouldn't matter for CGI Koha, but I'm curious how this might affect
Plack Koha. I haven't looked yet, but I figured it was worth sharing my
observation. I suppose Plack recycles workers, so it's not dangerous, but I
wonder if this is affecting the memory usage of Plack workers. Food for
thought at least.

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181219/91cf87ce/attachment.html>

From fridolin.somers at biblibre.com  Wed Dec 19 09:19:30 2018
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Wed, 19 Dec 2018 09:19:30 +0100
Subject: [Koha-devel] Possible memory leak when using ZOOM libraries
 with Zebra
In-Reply-To: <011b01d49737$512bd6d0$f3838470$@prosentient.com.au>
References: <011b01d49737$512bd6d0$f3838470$@prosentient.com.au>
Message-ID: <548fca13-c3e9-489b-78a6-f4dc0f71008c@biblibre.com>

Thanks for this alert.
Zebra is a wild animal ;)

Le 19/12/2018 ? 02:08, David Cook a ?crit?:
> Hi all,
> 
>   
> 
> I've been playing with the ZOOM libraries and Zebra, and it seems like
> there's a memory leak when using C4::Context->Zconn with the environmental
> variable GATEWAY_INTERFACE.
> 
>   
> 
> I had a script that was creating a new connection for each request, and
> C4::Context->Zconn did look like it was calling the destroy method on the
> connection before creating a new one, and it was clear that each request was
> using a new connection, but I noticed the memory usage on the script slowly
> started going up. For a long-running script, the memory usage got over a
> gigabyte.
> 
>   
> 
> If I re-use the connection (ie don't have GATEWAY_INTERFACE turned on),
> there's no memory leak.
> 
>   
> 
> It shouldn't matter for CGI Koha, but I'm curious how this might affect
> Plack Koha. I haven't looked yet, but I figured it was worth sharing my
> observation. I suppose Plack recycles workers, so it's not dangerous, but I
> wonder if this is affecting the memory usage of Plack workers. Food for
> thought at least.
> 
>   
> 
> David Cook
> 
> Systems Librarian
> 
> Prosentient Systems
> 
> 72/330 Wattle St
> 
> Ultimo, NSW 2007
> 
> Australia
> 
>   
> 
> Office: 02 9212 0899
> 
> Direct: 02 8005 0595
> 
>   
> 
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
BibLibre, France - software and system maintainer

From paul.poulain at biblibre.com  Wed Dec 19 09:33:04 2018
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 19 Dec 2018 09:33:04 +0100
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CAJzKNY6s4c9uznyd1G0ZwRm66QucYhE_MGQGcp2zPnLf3sB7RA@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
	<467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
	<CAJzKNY6s4c9uznyd1G0ZwRm66QucYhE_MGQGcp2zPnLf3sB7RA@mail.gmail.com>
Message-ID: <714610fc-33ad-c230-de45-76c57f67cb07@biblibre.com>

Hi Jonathan,

I'd be very happy if you could wrote something on the wiki, I'm a little 
bit confused by all those cache...

Le 07/12/2018 ? 16:36, Jonathan Druart a ?crit?:
> I talked with Ere on IRC, but prefer to let a note here as well.
>
> Enabling Cache::Memory if Plack is not running will not help as we
> have the L1 (in memory) cache, which is used in any cases (and flushed
> under Plack before a request is made).
>
> I do not know how is our caching system understood by the team. I can
> try and write something on the wiki if it can help. Hint: there is no
> black magic :)
>
> Cheers,
> Jonathan
>
> Le ven. 7 d?c. 2018 ? 04:55, Ere Maijala <ere.maijala at helsinki.fi> a ?crit :
>> I'm a bit hesitant on this. I understand running without a cache makes
>> things like tests easier, but Cache::Memory is actually a pretty useful
>> fallback. There's a lot of code in Koha that does redundant fetches of
>> e.g. framework data, and without caching I'm afraid it will slow down
>> significantly. Cache::Memory is very handy when developing stuff to
>> speed up execution of e.g. batch utilities when you don't want to mess
>> with constantly flushing Memcached.
>>
>> I would like to propose another approach for considerarion: disable
>> Cache::Memory only if running under Plack.
>>
>> --Ere
>>
>> David Cook kirjoitti 7.12.2018 klo 1.52:
>>> I?ve noticed some caching issues but haven?t had time to investigate too
>>> deeply. I wonder if this relates to what I?ve encountered.
>>>
>>>
>>>
>>> In any case, +1!
>>>
>>>
>>>
>>> David Cook
>>>
>>> Systems Librarian
>>>
>>> Prosentient Systems
>>>
>>> 72/330 Wattle St
>>>
>>> Ultimo, NSW 2007
>>>
>>> Australia
>>>
>>>
>>>
>>> Office: 02 9212 0899
>>>
>>> Direct: 02 8005 0595
>>>
>>>
>>>
>>> *From:*koha-devel-bounces at lists.koha-community.org
>>> [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
>>> *Tomas Cohen Arazi
>>> *Sent:* Friday, 7 December 2018 2:44 AM
>>> *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
>>> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
>>> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
>>>
>>>
>>>
>>> Get rid of it!
>>>
>>>
>>>
>>> +1
>>>
>>>
>>>
>>> El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
>>> (<jonathan.druart at bugs.koha-community.org
>>> <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
>>>
>>>      Hi devs,
>>>
>>>      I am still recovering from my holidays and I think I caught a quite
>>>      big fish.
>>>
>>>      After an interesting track game I will explain why I am suggesting to
>>>      remove Cache::Memory that is currently used as fallback for the L2
>>>      cache.
>>>
>>>      What I tried to fix:
>>>      Jenkins is complaining about selenium tests (regressions.t) failing on
>>>      18.05, it is a succession of events and bugs that were not linked at
>>>      first glance.
>>>
>>>      Here are the different steps I went though:
>>>      - On bug 21426 we noticed that USE_MEMCACHED was not taken into
>>>      account. If set to "no" the default memcached config was defined in
>>>      the koha-config.xml file anyway
>>>      - A new regression selenium test was added on bug 21777 to catch the
>>>      presence of an audio alert on the circulation page
>>>      - Investigating the failing tests I noticed that koha-testing-docker
>>>      was not setting the memcached config on the 18.05 branches (I guess
>>>      the image has not been rebuilt yet)
>>>      search_utf8.t output "Warning: script running in daemon mode, without
>>>      recommended caching system (memcached)."
>>>      - I also find that [% Koha.Preference('AudioAlerts') %] did not return
>>>      the value set by the tests, but the value that the DB has before the
>>>      tests were launched
>>>      => It is a cache issue!
>>>      - ...but only when memcached is not set...
>>>      - Reading Koha::Cache->new we can notice that Cache::Memory is used
>>>      for the L2 cache when memcached is not defined in the config
>>>
>>>      And so we have the problem: If a value is set in the cache by a Plack
>>>      worker, it will not be available from another one, as the L2 cache is
>>>      not shared (!)
>>>
>>>      To recreate easily the problem you can:
>>>      - remove the memcached config
>>>      - edit intranet-bottom.inc and add
>>>      ===[% Koha.Preference('AudioAlerts') %]===
>>>      - restart plack
>>>      - Modify the value of AudioAlerts (using the UI)
>>>      - Reload the page (reload several times if the value is still correct,
>>>      it will depend on which worker will serve the request)
>>>
>>>      Solution:
>>>      I am considering removing Cache::Memory unless somebody else has a
>>>      better idea
>>>      Bug 21955 - Cache::Memory should not be used as L2 cache
>>>
>>>      Note that it should not affect a lot of people as everybody is
>>>      supposed to have memcached configured and working correctly!
>>>
>>>      Cheers,
>>>      Jonathan
>>>      _______________________________________________
>>>      Koha-devel mailing list
>>>      Koha-devel at lists.koha-community.org
>>>      <mailto:Koha-devel at 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/
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Tom?s Cohen Arazi
>>>
>>> Theke Solutions (http://theke.io <http://theke.io/>)
>>> ?+54 9351 3513384
>>> GPG: B2F3C15F
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>>>
>> --
>> Ere Maijala
>> Kansalliskirjasto / The National Library of Finland
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries


From martin.renvoize at ptfs-europe.com  Thu Dec 20 14:06:13 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Thu, 20 Dec 2018 13:06:13 +0000
Subject: [Koha-devel] Koha 18.11.01 release
Message-ID: <CAB7SL8DWpfjsCm+3Jhdg0otTHZ03tDhxo8shhMqkjy01ycW-zA@mail.gmail.com>

The Koha community is proud to announce the release of Koha 18.11.01.

Please note, this release removes support for using Cache::Memory as your
caching strategy due to unresolvable bugs with its implementation which
cause issues in plack environments.  memcached has been the recommended
caching module for some time now, so anyone still relying on Cache::Memory
should consider migrating to Memcached.

This is a maintenance release containing 35 bugfixes

The full release notes are available at
*https://koha-community.org/koha-18-11-01-release/
<https://koha-community.org/koha-18-11-01-release/>*

Debian packages will be updated within a few days

That just leaves me to wish everyone a Happy Christmas and express my
thanks to everyone involved in this release,

*Martin Renvoize*

<https://www.ptfs-europe.com>

Development Team Manager





*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7725 985 636

*Email:* martin.renvoize at ptfs-europe.com

*Fax:* +44 (0) 800 756 6384


www.ptfs-europe.com







Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181220/d29d5173/attachment.html>

From martin.renvoize at ptfs-europe.com  Fri Dec 21 09:26:14 2018
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Fri, 21 Dec 2018 08:26:14 +0000
Subject: [Koha-devel] [Koha] 18.05.07 Released
In-Reply-To: <CABV14nMt=g1uTXanYLRQsumZS6SuwE=eKce_LTkqdt31HQH+vA@mail.gmail.com>
References: <CABV14nMt=g1uTXanYLRQsumZS6SuwE=eKce_LTkqdt31HQH+vA@mail.gmail.com>
Message-ID: <CAB7SL8A-6ckjXK5aX-LfRcq7_r1MFmC+_46+Ks49FnuNZhtBcw@mail.gmail.com>

Congratulations on your first release guys, that first one is always the
hardest :)


*Martin Renvoize*

<https://www.ptfs-europe.com>

Development Team Manager





*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7725 985 636

*Email:* martin.renvoize at ptfs-europe.com

*Fax:* +44 (0) 800 756 6384


www.ptfs-europe.com







Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com



On Thu, 20 Dec 2018 at 20:37, Jesse Maseto <jesse at bywatersolutions.com>
wrote:

> The Koha community is proud to announce the release of Koha 18.05.07.
>
> Please note, this release removes support for using Cache::Memory as your
> caching strategy due to unresolvable bugs with its implementation which
> cause issues in plack environments.  memcached has been the recommended
> caching module for some time now, so anyone still relying on Cache::Memory
> should consider migrating to Memcached.
>
> This is a maintenance release that includes 2 enhancements, 28 bugfixes.
>
> The full release notes are available at https://koha-community.org/
> koha-18-05-07-released/
> <https://koha-community.org/koha-18-05-07-released/>
>
> Debian packages will be updated within a few days.
>
> Best Regards,
> Jesse and Lucas
>
> --------------------
> Jesse Maseto
> Dev/Ops Support
> ByWater Solutions
> Support & Consulting for OSS
> Office - Stratford,CT
> T/F 888.900.8944
> http://bywatersolutions.com
> Jesse at bywatersolutions.com
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181221/155cba0d/attachment.html>

From fridolin.somers at biblibre.com  Fri Dec 21 10:49:33 2018
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Fri, 21 Dec 2018 10:49:33 +0100
Subject: [Koha-devel] Koha 17.11.13 release
Message-ID: <c647621c-2661-7ff7-e3e3-39c340719921@biblibre.com>

The Koha community is proud to announce the release of Koha 17.11.13.

This is a maintenance release.

The full release notes are available at 
https://koha-community.org/koha-17-11-13-release/

Debian packages will be upgraded in a few days.

Pay attention to Bug 21955 integration : Cache::Memory should not be 
used as L2 cache.
This means Memcached is more than recommanded on production servers.

Have a nice end of the year and merry christmas ;)

Hohoho,

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
BibLibre, France - software and system maintainer

From fridolin.somers at biblibre.com  Fri Dec 21 11:29:47 2018
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Fri, 21 Dec 2018 11:29:47 +0100
Subject: [Koha-devel] [Koha] 18.05.07 Released
In-Reply-To: <CAB7SL8A-6ckjXK5aX-LfRcq7_r1MFmC+_46+Ks49FnuNZhtBcw@mail.gmail.com>
References: <CABV14nMt=g1uTXanYLRQsumZS6SuwE=eKce_LTkqdt31HQH+vA@mail.gmail.com>
	<CAB7SL8A-6ckjXK5aX-LfRcq7_r1MFmC+_46+Ks49FnuNZhtBcw@mail.gmail.com>
Message-ID: <1e365339-2837-d78e-b7c7-304dcf401138@biblibre.com>

Congratulations guys,
Your work is usefull for the entier word ;)
Keep rolling little stones...

Le 21/12/2018 ? 09:26, Renvoize, Martin a ?crit?:
> Congratulations on your first release guys, that first one is always the
> hardest :)
> 
> 
> *Martin Renvoize*
> 
> <https://www.ptfs-europe.com>
> 
> Development Team Manager
> 
> 
> 
> 
> 
> *Phone:* +44 (0) 1483 378728
> 
> *Mobile:* +44 (0) 7725 985 636
> 
> *Email:* martin.renvoize at ptfs-europe.com
> 
> *Fax:* +44 (0) 800 756 6384
> 
> 
> www.ptfs-europe.com
> 
> 
> 
> 
> 
> 
> 
> Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30
> 
> The information contained in this email message may be privileged,
> confidential and protected from disclosure. If you are not the intended
> recipient, any dissemination, distribution or copying is strictly
> prohibited. If you think that you have received this email message in
> error, please email the sender at info at ptfs-europe.com
> 
> 
> 
> On Thu, 20 Dec 2018 at 20:37, Jesse Maseto <jesse at bywatersolutions.com>
> wrote:
> 
>> The Koha community is proud to announce the release of Koha 18.05.07.
>>
>> Please note, this release removes support for using Cache::Memory as your
>> caching strategy due to unresolvable bugs with its implementation which
>> cause issues in plack environments.  memcached has been the recommended
>> caching module for some time now, so anyone still relying on Cache::Memory
>> should consider migrating to Memcached.
>>
>> This is a maintenance release that includes 2 enhancements, 28 bugfixes.
>>
>> The full release notes are available at https://koha-community.org/
>> koha-18-05-07-released/
>> <https://koha-community.org/koha-18-05-07-released/>
>>
>> Debian packages will be updated within a few days.
>>
>> Best Regards,
>> Jesse and Lucas
>>
>> --------------------
>> Jesse Maseto
>> Dev/Ops Support
>> ByWater Solutions
>> Support & Consulting for OSS
>> Office - Stratford,CT
>> T/F 888.900.8944
>> http://bywatersolutions.com
>> Jesse at bywatersolutions.com
>> _______________________________________________
>> Koha mailing list  http://koha-community.org
>> Koha at lists.katipo.co.nz
>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
BibLibre, France - software and system maintainer

From nick at bywatersolutions.com  Fri Dec 21 12:46:11 2018
From: nick at bywatersolutions.com (Nick Clemens)
Date: Fri, 21 Dec 2018 06:46:11 -0500
Subject: [Koha-devel] [Koha] 18.05.07 Released
In-Reply-To: <1e365339-2837-d78e-b7c7-304dcf401138@biblibre.com>
References: <CABV14nMt=g1uTXanYLRQsumZS6SuwE=eKce_LTkqdt31HQH+vA@mail.gmail.com>
	<CAB7SL8A-6ckjXK5aX-LfRcq7_r1MFmC+_46+Ks49FnuNZhtBcw@mail.gmail.com>
	<1e365339-2837-d78e-b7c7-304dcf401138@biblibre.com>
Message-ID: <CAA_eX3PGsOSY4Dp3mZTVut9+xhmxCcYtGWWoC4vRYT94vv9Rfw@mail.gmail.com>

Excellent! You guys rock!

On Fri, Dec 21, 2018 at 5:29 AM Fridolin SOMERS <
fridolin.somers at biblibre.com> wrote:

> Congratulations guys,
> Your work is usefull for the entier word ;)
> Keep rolling little stones...
>
> Le 21/12/2018 ? 09:26, Renvoize, Martin a ?crit :
> > Congratulations on your first release guys, that first one is always the
> > hardest :)
> >
> >
> > *Martin Renvoize*
> >
> > <https://www.ptfs-europe.com>
> >
> > Development Team Manager
> >
> >
> >
> >
> >
> > *Phone:* +44 (0) 1483 378728
> >
> > *Mobile:* +44 (0) 7725 985 636
> >
> > *Email:* martin.renvoize at ptfs-europe.com
> >
> > *Fax:* +44 (0) 800 756 6384
> >
> >
> > www.ptfs-europe.com
> >
> >
> >
> >
> >
> >
> >
> > Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30
> >
> > The information contained in this email message may be privileged,
> > confidential and protected from disclosure. If you are not the intended
> > recipient, any dissemination, distribution or copying is strictly
> > prohibited. If you think that you have received this email message in
> > error, please email the sender at info at ptfs-europe.com
> >
> >
> >
> > On Thu, 20 Dec 2018 at 20:37, Jesse Maseto <jesse at bywatersolutions.com>
> > wrote:
> >
> >> The Koha community is proud to announce the release of Koha 18.05.07.
> >>
> >> Please note, this release removes support for using Cache::Memory as
> your
> >> caching strategy due to unresolvable bugs with its implementation which
> >> cause issues in plack environments.  memcached has been the recommended
> >> caching module for some time now, so anyone still relying on
> Cache::Memory
> >> should consider migrating to Memcached.
> >>
> >> This is a maintenance release that includes 2 enhancements, 28 bugfixes.
> >>
> >> The full release notes are available at https://koha-community.org/
> >> koha-18-05-07-released/
> >> <https://koha-community.org/koha-18-05-07-released/>
> >>
> >> Debian packages will be updated within a few days.
> >>
> >> Best Regards,
> >> Jesse and Lucas
> >>
> >> --------------------
> >> Jesse Maseto
> >> Dev/Ops Support
> >> ByWater Solutions
> >> Support & Consulting for OSS
> >> Office - Stratford,CT
> >> T/F 888.900.8944
> >> http://bywatersolutions.com
> >> Jesse at bywatersolutions.com
> >> _______________________________________________
> >> Koha mailing list  http://koha-community.org
> >> Koha at lists.katipo.co.nz
> >> https://lists.katipo.co.nz/mailman/listinfo/koha
> >>
> >
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
> >
>
> --
> Fridolin SOMERS <fridolin.somers at biblibre.com>
> BibLibre, France - software and system maintainer
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181221/516b7678/attachment.html>

From kohadevinim at devinim.com.tr  Fri Dec 21 12:59:15 2018
From: kohadevinim at devinim.com.tr (DevinimKoha)
Date: Fri, 21 Dec 2018 14:59:15 +0300
Subject: [Koha-devel] [Koha] 18.05.07 Released
In-Reply-To: <CAA_eX3PGsOSY4Dp3mZTVut9+xhmxCcYtGWWoC4vRYT94vv9Rfw@mail.gmail.com>
References: <CABV14nMt=g1uTXanYLRQsumZS6SuwE=eKce_LTkqdt31HQH+vA@mail.gmail.com>
	<CAB7SL8A-6ckjXK5aX-LfRcq7_r1MFmC+_46+Ks49FnuNZhtBcw@mail.gmail.com>
	<1e365339-2837-d78e-b7c7-304dcf401138@biblibre.com>
	<CAA_eX3PGsOSY4Dp3mZTVut9+xhmxCcYtGWWoC4vRYT94vv9Rfw@mail.gmail.com>
Message-ID: <a68d9b7e-8654-9474-99fa-4670755a34f5@devinim.com.tr>

Yes, we congratulate all of you!

All individual of Koha community is doing wonderful enhancements.


On 21.12.2018 14:46, Nick Clemens wrote:
> Excellent! You guys rock!
>
> On Fri, Dec 21, 2018 at 5:29 AM Fridolin SOMERS 
> <fridolin.somers at biblibre.com <mailto:fridolin.somers at biblibre.com>> 
> wrote:
>
>     Congratulations guys,
>     Your work is usefull for the entier word ;)
>     Keep rolling little stones...
>
>     Le 21/12/2018 ? 09:26, Renvoize, Martin a ?crit?:
>     > Congratulations on your first release guys, that first one is
>     always the
>     > hardest :)
>     >
>     >
>     > *Martin Renvoize*
>     >
>     > <https://www.ptfs-europe.com>
>     >
>     > Development Team Manager
>     >
>     >
>     >
>     >
>     >
>     > *Phone:* +44 (0) 1483 378728
>     >
>     > *Mobile:* +44 (0) 7725 985 636
>     >
>     > *Email:* martin.renvoize at ptfs-europe.com
>     <mailto:martin.renvoize at ptfs-europe.com>
>     >
>     > *Fax:* +44 (0) 800 756 6384
>     >
>     >
>     > www.ptfs-europe.com <http://www.ptfs-europe.com>
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     > Registered in the United Kingdom No. 06416372? ?VAT Reg No. 925
>     7211 30
>     >
>     > The information contained in this email message may be privileged,
>     > confidential and protected from disclosure. If you are not the
>     intended
>     > recipient, any dissemination, distribution or copying is strictly
>     > prohibited. If you think that you have received this email
>     message in
>     > error, please email the sender at info at ptfs-europe.com
>     <mailto:info at ptfs-europe.com>
>     >
>     >
>     >
>     > On Thu, 20 Dec 2018 at 20:37, Jesse Maseto
>     <jesse at bywatersolutions.com <mailto:jesse at bywatersolutions.com>>
>     > wrote:
>     >
>     >> The Koha community is proud to announce the release of Koha
>     18.05.07.
>     >>
>     >> Please note, this release removes support for using
>     Cache::Memory as your
>     >> caching strategy due to unresolvable bugs with its
>     implementation which
>     >> cause issues in plack environments.? memcached has been the
>     recommended
>     >> caching module for some time now, so anyone still relying on
>     Cache::Memory
>     >> should consider migrating to Memcached.
>     >>
>     >> This is a maintenance release that includes 2 enhancements, 28
>     bugfixes.
>     >>
>     >> The full release notes are available at https://koha-community.org/
>     >> koha-18-05-07-released/
>     >> <https://koha-community.org/koha-18-05-07-released/>
>     >>
>     >> Debian packages will be updated within a few days.
>     >>
>     >> Best Regards,
>     >> Jesse and Lucas
>     >>
>     >> --------------------
>     >> Jesse Maseto
>     >> Dev/Ops Support
>     >> ByWater Solutions
>     >> Support & Consulting for OSS
>     >> Office - Stratford,CT
>     >> T/F 888.900.8944
>     >> http://bywatersolutions.com
>     >> Jesse at bywatersolutions.com <mailto:Jesse at bywatersolutions.com>
>     >> _______________________________________________
>     >> Koha mailing list http://koha-community.org
>     >> Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>     >> https://lists.katipo.co.nz/mailman/listinfo/koha
>     >>
>     >
>     >
>     > _______________________________________________
>     > Koha-devel mailing list
>     > Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>     >
>
>     -- 
>     Fridolin SOMERS <fridolin.somers at biblibre.com
>     <mailto:fridolin.somers at biblibre.com>>
>     BibLibre, France - software and system maintainer
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181221/65d7490e/attachment-0001.html>

From jonathan.druart at bugs.koha-community.org  Fri Dec 21 16:51:01 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 21 Dec 2018 12:51:01 -0300
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <714610fc-33ad-c230-de45-76c57f67cb07@biblibre.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
	<467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
	<CAJzKNY6s4c9uznyd1G0ZwRm66QucYhE_MGQGcp2zPnLf3sB7RA@mail.gmail.com>
	<714610fc-33ad-c230-de45-76c57f67cb07@biblibre.com>
Message-ID: <CAJzKNY7NBss30bB_Q=g4=jpOM89gpoRzmmWw2cjEx2KKafPX3w@mail.gmail.com>

I have stolen this existing page and wrote some info about our cache mechanism:
https://wiki.koha-community.org/wiki/Cache_handling_in_Koha

Feel free to ask if you need more info or if something is still not
clear enough.

Cheers,
Jonathan

Le mer. 19 d?c. 2018 ? 05:33, Paul Poulain <paul.poulain at biblibre.com> a ?crit :
>
> Hi Jonathan,
>
> I'd be very happy if you could wrote something on the wiki, I'm a little
> bit confused by all those cache...
>
> Le 07/12/2018 ? 16:36, Jonathan Druart a ?crit :
> > I talked with Ere on IRC, but prefer to let a note here as well.
> >
> > Enabling Cache::Memory if Plack is not running will not help as we
> > have the L1 (in memory) cache, which is used in any cases (and flushed
> > under Plack before a request is made).
> >
> > I do not know how is our caching system understood by the team. I can
> > try and write something on the wiki if it can help. Hint: there is no
> > black magic :)
> >
> > Cheers,
> > Jonathan
> >
> > Le ven. 7 d?c. 2018 ? 04:55, Ere Maijala <ere.maijala at helsinki.fi> a ?crit :
> >> I'm a bit hesitant on this. I understand running without a cache makes
> >> things like tests easier, but Cache::Memory is actually a pretty useful
> >> fallback. There's a lot of code in Koha that does redundant fetches of
> >> e.g. framework data, and without caching I'm afraid it will slow down
> >> significantly. Cache::Memory is very handy when developing stuff to
> >> speed up execution of e.g. batch utilities when you don't want to mess
> >> with constantly flushing Memcached.
> >>
> >> I would like to propose another approach for considerarion: disable
> >> Cache::Memory only if running under Plack.
> >>
> >> --Ere
> >>
> >> David Cook kirjoitti 7.12.2018 klo 1.52:
> >>> I?ve noticed some caching issues but haven?t had time to investigate too
> >>> deeply. I wonder if this relates to what I?ve encountered.
> >>>
> >>>
> >>>
> >>> In any case, +1!
> >>>
> >>>
> >>>
> >>> David Cook
> >>>
> >>> Systems Librarian
> >>>
> >>> Prosentient Systems
> >>>
> >>> 72/330 Wattle St
> >>>
> >>> Ultimo, NSW 2007
> >>>
> >>> Australia
> >>>
> >>>
> >>>
> >>> Office: 02 9212 0899
> >>>
> >>> Direct: 02 8005 0595
> >>>
> >>>
> >>>
> >>> *From:*koha-devel-bounces at lists.koha-community.org
> >>> [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
> >>> *Tomas Cohen Arazi
> >>> *Sent:* Friday, 7 December 2018 2:44 AM
> >>> *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
> >>> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
> >>> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
> >>>
> >>>
> >>>
> >>> Get rid of it!
> >>>
> >>>
> >>>
> >>> +1
> >>>
> >>>
> >>>
> >>> El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
> >>> (<jonathan.druart at bugs.koha-community.org
> >>> <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
> >>>
> >>>      Hi devs,
> >>>
> >>>      I am still recovering from my holidays and I think I caught a quite
> >>>      big fish.
> >>>
> >>>      After an interesting track game I will explain why I am suggesting to
> >>>      remove Cache::Memory that is currently used as fallback for the L2
> >>>      cache.
> >>>
> >>>      What I tried to fix:
> >>>      Jenkins is complaining about selenium tests (regressions.t) failing on
> >>>      18.05, it is a succession of events and bugs that were not linked at
> >>>      first glance.
> >>>
> >>>      Here are the different steps I went though:
> >>>      - On bug 21426 we noticed that USE_MEMCACHED was not taken into
> >>>      account. If set to "no" the default memcached config was defined in
> >>>      the koha-config.xml file anyway
> >>>      - A new regression selenium test was added on bug 21777 to catch the
> >>>      presence of an audio alert on the circulation page
> >>>      - Investigating the failing tests I noticed that koha-testing-docker
> >>>      was not setting the memcached config on the 18.05 branches (I guess
> >>>      the image has not been rebuilt yet)
> >>>      search_utf8.t output "Warning: script running in daemon mode, without
> >>>      recommended caching system (memcached)."
> >>>      - I also find that [% Koha.Preference('AudioAlerts') %] did not return
> >>>      the value set by the tests, but the value that the DB has before the
> >>>      tests were launched
> >>>      => It is a cache issue!
> >>>      - ...but only when memcached is not set...
> >>>      - Reading Koha::Cache->new we can notice that Cache::Memory is used
> >>>      for the L2 cache when memcached is not defined in the config
> >>>
> >>>      And so we have the problem: If a value is set in the cache by a Plack
> >>>      worker, it will not be available from another one, as the L2 cache is
> >>>      not shared (!)
> >>>
> >>>      To recreate easily the problem you can:
> >>>      - remove the memcached config
> >>>      - edit intranet-bottom.inc and add
> >>>      ===[% Koha.Preference('AudioAlerts') %]===
> >>>      - restart plack
> >>>      - Modify the value of AudioAlerts (using the UI)
> >>>      - Reload the page (reload several times if the value is still correct,
> >>>      it will depend on which worker will serve the request)
> >>>
> >>>      Solution:
> >>>      I am considering removing Cache::Memory unless somebody else has a
> >>>      better idea
> >>>      Bug 21955 - Cache::Memory should not be used as L2 cache
> >>>
> >>>      Note that it should not affect a lot of people as everybody is
> >>>      supposed to have memcached configured and working correctly!
> >>>
> >>>      Cheers,
> >>>      Jonathan
> >>>      _______________________________________________
> >>>      Koha-devel mailing list
> >>>      Koha-devel at lists.koha-community.org
> >>>      <mailto:Koha-devel at 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/
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Tom?s Cohen Arazi
> >>>
> >>> Theke Solutions (http://theke.io <http://theke.io/>)
> >>> ?+54 9351 3513384
> >>> GPG: B2F3C15F
> >>>
> >>>
> >>> _______________________________________________
> >>> Koha-devel mailing list
> >>> Koha-devel at 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/
> >>>
> >> --
> >> Ere Maijala
> >> Kansalliskirjasto / The National Library of Finland
> >>
> >> _______________________________________________
> >> Koha-devel mailing list
> >> Koha-devel at 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/
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
>
> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From paul.poulain at biblibre.com  Fri Dec 21 17:01:22 2018
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 21 Dec 2018 17:01:22 +0100
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <CAJzKNY7NBss30bB_Q=g4=jpOM89gpoRzmmWw2cjEx2KKafPX3w@mail.gmail.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
	<467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
	<CAJzKNY6s4c9uznyd1G0ZwRm66QucYhE_MGQGcp2zPnLf3sB7RA@mail.gmail.com>
	<714610fc-33ad-c230-de45-76c57f67cb07@biblibre.com>
	<CAJzKNY7NBss30bB_Q=g4=jpOM89gpoRzmmWw2cjEx2KKafPX3w@mail.gmail.com>
Message-ID: <47286f1d-c184-3a0e-bb44-c868228c6d56@biblibre.com>

Great, thanks !

An idea: couldn't we also cache the xslt display of biblios, as it 
requires quite a long time to be done, and it's a data that change rarely ?

Le 21/12/2018 ? 16:51, Jonathan Druart a ?crit?:
> I have stolen this existing page and wrote some info about our cache mechanism:
> https://wiki.koha-community.org/wiki/Cache_handling_in_Koha
>
> Feel free to ask if you need more info or if something is still not
> clear enough.
>
> Cheers,
> Jonathan
>
> Le mer. 19 d?c. 2018 ? 05:33, Paul Poulain <paul.poulain at biblibre.com> a ?crit :
>> Hi Jonathan,
>>
>> I'd be very happy if you could wrote something on the wiki, I'm a little
>> bit confused by all those cache...
>>
>> Le 07/12/2018 ? 16:36, Jonathan Druart a ?crit :
>>> I talked with Ere on IRC, but prefer to let a note here as well.
>>>
>>> Enabling Cache::Memory if Plack is not running will not help as we
>>> have the L1 (in memory) cache, which is used in any cases (and flushed
>>> under Plack before a request is made).
>>>
>>> I do not know how is our caching system understood by the team. I can
>>> try and write something on the wiki if it can help. Hint: there is no
>>> black magic :)
>>>
>>> Cheers,
>>> Jonathan
>>>
>>> Le ven. 7 d?c. 2018 ? 04:55, Ere Maijala <ere.maijala at helsinki.fi> a ?crit :
>>>> I'm a bit hesitant on this. I understand running without a cache makes
>>>> things like tests easier, but Cache::Memory is actually a pretty useful
>>>> fallback. There's a lot of code in Koha that does redundant fetches of
>>>> e.g. framework data, and without caching I'm afraid it will slow down
>>>> significantly. Cache::Memory is very handy when developing stuff to
>>>> speed up execution of e.g. batch utilities when you don't want to mess
>>>> with constantly flushing Memcached.
>>>>
>>>> I would like to propose another approach for considerarion: disable
>>>> Cache::Memory only if running under Plack.
>>>>
>>>> --Ere
>>>>
>>>> David Cook kirjoitti 7.12.2018 klo 1.52:
>>>>> I?ve noticed some caching issues but haven?t had time to investigate too
>>>>> deeply. I wonder if this relates to what I?ve encountered.
>>>>>
>>>>>
>>>>>
>>>>> In any case, +1!
>>>>>
>>>>>
>>>>>
>>>>> David Cook
>>>>>
>>>>> Systems Librarian
>>>>>
>>>>> Prosentient Systems
>>>>>
>>>>> 72/330 Wattle St
>>>>>
>>>>> Ultimo, NSW 2007
>>>>>
>>>>> Australia
>>>>>
>>>>>
>>>>>
>>>>> Office: 02 9212 0899
>>>>>
>>>>> Direct: 02 8005 0595
>>>>>
>>>>>
>>>>>
>>>>> *From:*koha-devel-bounces at lists.koha-community.org
>>>>> [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
>>>>> *Tomas Cohen Arazi
>>>>> *Sent:* Friday, 7 December 2018 2:44 AM
>>>>> *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
>>>>> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
>>>>> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
>>>>>
>>>>>
>>>>>
>>>>> Get rid of it!
>>>>>
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>
>>>>> El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
>>>>> (<jonathan.druart at bugs.koha-community.org
>>>>> <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
>>>>>
>>>>>       Hi devs,
>>>>>
>>>>>       I am still recovering from my holidays and I think I caught a quite
>>>>>       big fish.
>>>>>
>>>>>       After an interesting track game I will explain why I am suggesting to
>>>>>       remove Cache::Memory that is currently used as fallback for the L2
>>>>>       cache.
>>>>>
>>>>>       What I tried to fix:
>>>>>       Jenkins is complaining about selenium tests (regressions.t) failing on
>>>>>       18.05, it is a succession of events and bugs that were not linked at
>>>>>       first glance.
>>>>>
>>>>>       Here are the different steps I went though:
>>>>>       - On bug 21426 we noticed that USE_MEMCACHED was not taken into
>>>>>       account. If set to "no" the default memcached config was defined in
>>>>>       the koha-config.xml file anyway
>>>>>       - A new regression selenium test was added on bug 21777 to catch the
>>>>>       presence of an audio alert on the circulation page
>>>>>       - Investigating the failing tests I noticed that koha-testing-docker
>>>>>       was not setting the memcached config on the 18.05 branches (I guess
>>>>>       the image has not been rebuilt yet)
>>>>>       search_utf8.t output "Warning: script running in daemon mode, without
>>>>>       recommended caching system (memcached)."
>>>>>       - I also find that [% Koha.Preference('AudioAlerts') %] did not return
>>>>>       the value set by the tests, but the value that the DB has before the
>>>>>       tests were launched
>>>>>       => It is a cache issue!
>>>>>       - ...but only when memcached is not set...
>>>>>       - Reading Koha::Cache->new we can notice that Cache::Memory is used
>>>>>       for the L2 cache when memcached is not defined in the config
>>>>>
>>>>>       And so we have the problem: If a value is set in the cache by a Plack
>>>>>       worker, it will not be available from another one, as the L2 cache is
>>>>>       not shared (!)
>>>>>
>>>>>       To recreate easily the problem you can:
>>>>>       - remove the memcached config
>>>>>       - edit intranet-bottom.inc and add
>>>>>       ===[% Koha.Preference('AudioAlerts') %]===
>>>>>       - restart plack
>>>>>       - Modify the value of AudioAlerts (using the UI)
>>>>>       - Reload the page (reload several times if the value is still correct,
>>>>>       it will depend on which worker will serve the request)
>>>>>
>>>>>       Solution:
>>>>>       I am considering removing Cache::Memory unless somebody else has a
>>>>>       better idea
>>>>>       Bug 21955 - Cache::Memory should not be used as L2 cache
>>>>>
>>>>>       Note that it should not affect a lot of people as everybody is
>>>>>       supposed to have memcached configured and working correctly!
>>>>>
>>>>>       Cheers,
>>>>>       Jonathan
>>>>>       _______________________________________________
>>>>>       Koha-devel mailing list
>>>>>       Koha-devel at lists.koha-community.org
>>>>>       <mailto:Koha-devel at 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/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Tom?s Cohen Arazi
>>>>>
>>>>> Theke Solutions (http://theke.io <http://theke.io/>)
>>>>> ?+54 9351 3513384
>>>>> GPG: B2F3C15F
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Koha-devel mailing list
>>>>> Koha-devel at 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/
>>>>>
>>>> --
>>>> Ere Maijala
>>>> Kansalliskirjasto / The National Library of Finland
>>>>
>>>> _______________________________________________
>>>> Koha-devel mailing list
>>>> Koha-devel at 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/
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>> --
>> Paul Poulain, Associ?-g?rant / co-owner
>> BibLibre, Services en logiciels libres pour les biblioth?ques
>> BibLibre, Open Source software and services for libraries
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/

-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries


From jonathan.druart at bugs.koha-community.org  Fri Dec 21 17:22:34 2018
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 21 Dec 2018 13:22:34 -0300
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <47286f1d-c184-3a0e-bb44-c868228c6d56@biblibre.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
	<467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
	<CAJzKNY6s4c9uznyd1G0ZwRm66QucYhE_MGQGcp2zPnLf3sB7RA@mail.gmail.com>
	<714610fc-33ad-c230-de45-76c57f67cb07@biblibre.com>
	<CAJzKNY7NBss30bB_Q=g4=jpOM89gpoRzmmWw2cjEx2KKafPX3w@mail.gmail.com>
	<47286f1d-c184-3a0e-bb44-c868228c6d56@biblibre.com>
Message-ID: <CAJzKNY5n1N7wF+B6wvqPKxQjG8RocSFEY54A5hPzFj=x8SR=AA@mail.gmail.com>

"There is a patch for that" :)

See bug 14476

Le ven. 21 d?c. 2018 ? 13:01, Paul Poulain <paul.poulain at biblibre.com> a ?crit :
>
> Great, thanks !
>
> An idea: couldn't we also cache the xslt display of biblios, as it
> requires quite a long time to be done, and it's a data that change rarely ?
>
> Le 21/12/2018 ? 16:51, Jonathan Druart a ?crit :
> > I have stolen this existing page and wrote some info about our cache mechanism:
> > https://wiki.koha-community.org/wiki/Cache_handling_in_Koha
> >
> > Feel free to ask if you need more info or if something is still not
> > clear enough.
> >
> > Cheers,
> > Jonathan
> >
> > Le mer. 19 d?c. 2018 ? 05:33, Paul Poulain <paul.poulain at biblibre.com> a ?crit :
> >> Hi Jonathan,
> >>
> >> I'd be very happy if you could wrote something on the wiki, I'm a little
> >> bit confused by all those cache...
> >>
> >> Le 07/12/2018 ? 16:36, Jonathan Druart a ?crit :
> >>> I talked with Ere on IRC, but prefer to let a note here as well.
> >>>
> >>> Enabling Cache::Memory if Plack is not running will not help as we
> >>> have the L1 (in memory) cache, which is used in any cases (and flushed
> >>> under Plack before a request is made).
> >>>
> >>> I do not know how is our caching system understood by the team. I can
> >>> try and write something on the wiki if it can help. Hint: there is no
> >>> black magic :)
> >>>
> >>> Cheers,
> >>> Jonathan
> >>>
> >>> Le ven. 7 d?c. 2018 ? 04:55, Ere Maijala <ere.maijala at helsinki.fi> a ?crit :
> >>>> I'm a bit hesitant on this. I understand running without a cache makes
> >>>> things like tests easier, but Cache::Memory is actually a pretty useful
> >>>> fallback. There's a lot of code in Koha that does redundant fetches of
> >>>> e.g. framework data, and without caching I'm afraid it will slow down
> >>>> significantly. Cache::Memory is very handy when developing stuff to
> >>>> speed up execution of e.g. batch utilities when you don't want to mess
> >>>> with constantly flushing Memcached.
> >>>>
> >>>> I would like to propose another approach for considerarion: disable
> >>>> Cache::Memory only if running under Plack.
> >>>>
> >>>> --Ere
> >>>>
> >>>> David Cook kirjoitti 7.12.2018 klo 1.52:
> >>>>> I?ve noticed some caching issues but haven?t had time to investigate too
> >>>>> deeply. I wonder if this relates to what I?ve encountered.
> >>>>>
> >>>>>
> >>>>>
> >>>>> In any case, +1!
> >>>>>
> >>>>>
> >>>>>
> >>>>> David Cook
> >>>>>
> >>>>> Systems Librarian
> >>>>>
> >>>>> Prosentient Systems
> >>>>>
> >>>>> 72/330 Wattle St
> >>>>>
> >>>>> Ultimo, NSW 2007
> >>>>>
> >>>>> Australia
> >>>>>
> >>>>>
> >>>>>
> >>>>> Office: 02 9212 0899
> >>>>>
> >>>>> Direct: 02 8005 0595
> >>>>>
> >>>>>
> >>>>>
> >>>>> *From:*koha-devel-bounces at lists.koha-community.org
> >>>>> [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
> >>>>> *Tomas Cohen Arazi
> >>>>> *Sent:* Friday, 7 December 2018 2:44 AM
> >>>>> *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
> >>>>> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
> >>>>> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
> >>>>>
> >>>>>
> >>>>>
> >>>>> Get rid of it!
> >>>>>
> >>>>>
> >>>>>
> >>>>> +1
> >>>>>
> >>>>>
> >>>>>
> >>>>> El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
> >>>>> (<jonathan.druart at bugs.koha-community.org
> >>>>> <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
> >>>>>
> >>>>>       Hi devs,
> >>>>>
> >>>>>       I am still recovering from my holidays and I think I caught a quite
> >>>>>       big fish.
> >>>>>
> >>>>>       After an interesting track game I will explain why I am suggesting to
> >>>>>       remove Cache::Memory that is currently used as fallback for the L2
> >>>>>       cache.
> >>>>>
> >>>>>       What I tried to fix:
> >>>>>       Jenkins is complaining about selenium tests (regressions.t) failing on
> >>>>>       18.05, it is a succession of events and bugs that were not linked at
> >>>>>       first glance.
> >>>>>
> >>>>>       Here are the different steps I went though:
> >>>>>       - On bug 21426 we noticed that USE_MEMCACHED was not taken into
> >>>>>       account. If set to "no" the default memcached config was defined in
> >>>>>       the koha-config.xml file anyway
> >>>>>       - A new regression selenium test was added on bug 21777 to catch the
> >>>>>       presence of an audio alert on the circulation page
> >>>>>       - Investigating the failing tests I noticed that koha-testing-docker
> >>>>>       was not setting the memcached config on the 18.05 branches (I guess
> >>>>>       the image has not been rebuilt yet)
> >>>>>       search_utf8.t output "Warning: script running in daemon mode, without
> >>>>>       recommended caching system (memcached)."
> >>>>>       - I also find that [% Koha.Preference('AudioAlerts') %] did not return
> >>>>>       the value set by the tests, but the value that the DB has before the
> >>>>>       tests were launched
> >>>>>       => It is a cache issue!
> >>>>>       - ...but only when memcached is not set...
> >>>>>       - Reading Koha::Cache->new we can notice that Cache::Memory is used
> >>>>>       for the L2 cache when memcached is not defined in the config
> >>>>>
> >>>>>       And so we have the problem: If a value is set in the cache by a Plack
> >>>>>       worker, it will not be available from another one, as the L2 cache is
> >>>>>       not shared (!)
> >>>>>
> >>>>>       To recreate easily the problem you can:
> >>>>>       - remove the memcached config
> >>>>>       - edit intranet-bottom.inc and add
> >>>>>       ===[% Koha.Preference('AudioAlerts') %]===
> >>>>>       - restart plack
> >>>>>       - Modify the value of AudioAlerts (using the UI)
> >>>>>       - Reload the page (reload several times if the value is still correct,
> >>>>>       it will depend on which worker will serve the request)
> >>>>>
> >>>>>       Solution:
> >>>>>       I am considering removing Cache::Memory unless somebody else has a
> >>>>>       better idea
> >>>>>       Bug 21955 - Cache::Memory should not be used as L2 cache
> >>>>>
> >>>>>       Note that it should not affect a lot of people as everybody is
> >>>>>       supposed to have memcached configured and working correctly!
> >>>>>
> >>>>>       Cheers,
> >>>>>       Jonathan
> >>>>>       _______________________________________________
> >>>>>       Koha-devel mailing list
> >>>>>       Koha-devel at lists.koha-community.org
> >>>>>       <mailto:Koha-devel at 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/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Tom?s Cohen Arazi
> >>>>>
> >>>>> Theke Solutions (http://theke.io <http://theke.io/>)
> >>>>> ?+54 9351 3513384
> >>>>> GPG: B2F3C15F
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Koha-devel mailing list
> >>>>> Koha-devel at 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/
> >>>>>
> >>>> --
> >>>> Ere Maijala
> >>>> Kansalliskirjasto / The National Library of Finland
> >>>>
> >>>> _______________________________________________
> >>>> Koha-devel mailing list
> >>>> Koha-devel at 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/
> >>> _______________________________________________
> >>> Koha-devel mailing list
> >>> Koha-devel at 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/
> >> --
> >> Paul Poulain, Associ?-g?rant / co-owner
> >> BibLibre, Services en logiciels libres pour les biblioth?ques
> >> BibLibre, Open Source software and services for libraries
> >>
> >> _______________________________________________
> >> Koha-devel mailing list
> >> Koha-devel at 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/
>
> --
> Paul Poulain, Associ?-g?rant / co-owner
> BibLibre, Services en logiciels libres pour les biblioth?ques
> BibLibre, Open Source software and services for libraries
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From M.de.Rooy at rijksmuseum.nl  Fri Dec 21 18:48:41 2018
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Fri, 21 Dec 2018 17:48:41 +0000
Subject: [Koha-devel] Cache::Memory must be removed (21955)
In-Reply-To: <47286f1d-c184-3a0e-bb44-c868228c6d56@biblibre.com>
References: <CAJzKNY6OCxjUMZbsfaP3hUZztmHJy4Nh9H76WBDSVaENbS+AhA@mail.gmail.com>
	<CABZfb=VQspkMRM-v432n3LO68KQDrEYOaxQPRhUP3uTOEcu+iw@mail.gmail.com>
	<03b801d48dbe$cbfe2480$63fa6d80$@prosentient.com.au>
	<467f18f3-ea1f-ce1b-8612-8cfb2db601fe@helsinki.fi>
	<CAJzKNY6s4c9uznyd1G0ZwRm66QucYhE_MGQGcp2zPnLf3sB7RA@mail.gmail.com>
	<714610fc-33ad-c230-de45-76c57f67cb07@biblibre.com>
	<CAJzKNY7NBss30bB_Q=g4=jpOM89gpoRzmmWw2cjEx2KKafPX3w@mail.gmail.com>,
	<47286f1d-c184-3a0e-bb44-c868228c6d56@biblibre.com>
Message-ID: <AM6PR05MB59762552C9A2434A48312183CEB80@AM6PR05MB5976.eurprd05.prod.outlook.com>

Look at XSLT_Handler ?

________________________________
Van: koha-devel-bounces at lists.koha-community.org <koha-devel-bounces at lists.koha-community.org> namens Paul Poulain <paul.poulain at biblibre.com>
Verzonden: vrijdag 21 december 2018 17:01
CC: koha-devel
Onderwerp: Re: [Koha-devel] Cache::Memory must be removed (21955)

Great, thanks !

An idea: couldn't we also cache the xslt display of biblios, as it
requires quite a long time to be done, and it's a data that change rarely ?

Le 21/12/2018 ? 16:51, Jonathan Druart a ?crit :
> I have stolen this existing page and wrote some info about our cache mechanism:
> https://wiki.koha-community.org/wiki/Cache_handling_in_Koha
>
> Feel free to ask if you need more info or if something is still not
> clear enough.
>
> Cheers,
> Jonathan
>
> Le mer. 19 d?c. 2018 ? 05:33, Paul Poulain <paul.poulain at biblibre.com> a ?crit :
>> Hi Jonathan,
>>
>> I'd be very happy if you could wrote something on the wiki, I'm a little
>> bit confused by all those cache...
>>
>> Le 07/12/2018 ? 16:36, Jonathan Druart a ?crit :
>>> I talked with Ere on IRC, but prefer to let a note here as well.
>>>
>>> Enabling Cache::Memory if Plack is not running will not help as we
>>> have the L1 (in memory) cache, which is used in any cases (and flushed
>>> under Plack before a request is made).
>>>
>>> I do not know how is our caching system understood by the team. I can
>>> try and write something on the wiki if it can help. Hint: there is no
>>> black magic :)
>>>
>>> Cheers,
>>> Jonathan
>>>
>>> Le ven. 7 d?c. 2018 ? 04:55, Ere Maijala <ere.maijala at helsinki.fi> a ?crit :
>>>> I'm a bit hesitant on this. I understand running without a cache makes
>>>> things like tests easier, but Cache::Memory is actually a pretty useful
>>>> fallback. There's a lot of code in Koha that does redundant fetches of
>>>> e.g. framework data, and without caching I'm afraid it will slow down
>>>> significantly. Cache::Memory is very handy when developing stuff to
>>>> speed up execution of e.g. batch utilities when you don't want to mess
>>>> with constantly flushing Memcached.
>>>>
>>>> I would like to propose another approach for considerarion: disable
>>>> Cache::Memory only if running under Plack.
>>>>
>>>> --Ere
>>>>
>>>> David Cook kirjoitti 7.12.2018 klo 1.52:
>>>>> I?ve noticed some caching issues but haven?t had time to investigate too
>>>>> deeply. I wonder if this relates to what I?ve encountered.
>>>>>
>>>>>
>>>>>
>>>>> In any case, +1!
>>>>>
>>>>>
>>>>>
>>>>> David Cook
>>>>>
>>>>> Systems Librarian
>>>>>
>>>>> Prosentient Systems
>>>>>
>>>>> 72/330 Wattle St
>>>>>
>>>>> Ultimo, NSW 2007
>>>>>
>>>>> Australia
>>>>>
>>>>>
>>>>>
>>>>> Office: 02 9212 0899
>>>>>
>>>>> Direct: 02 8005 0595
>>>>>
>>>>>
>>>>>
>>>>> *From:*koha-devel-bounces at lists.koha-community.org
>>>>> [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of
>>>>> *Tomas Cohen Arazi
>>>>> *Sent:* Friday, 7 December 2018 2:44 AM
>>>>> *To:* Jonathan Druart <jonathan.druart at bugs.koha-community.org>
>>>>> *Cc:* koha-devel <koha-devel at lists.koha-community.org>
>>>>> *Subject:* Re: [Koha-devel] Cache::Memory must be removed (21955)
>>>>>
>>>>>
>>>>>
>>>>> Get rid of it!
>>>>>
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>
>>>>> El mi?., 5 dic. 2018 a las 16:20, Jonathan Druart
>>>>> (<jonathan.druart at bugs.koha-community.org
>>>>> <mailto:jonathan.druart at bugs.koha-community.org>>) escribi?:
>>>>>
>>>>>       Hi devs,
>>>>>
>>>>>       I am still recovering from my holidays and I think I caught a quite
>>>>>       big fish.
>>>>>
>>>>>       After an interesting track game I will explain why I am suggesting to
>>>>>       remove Cache::Memory that is currently used as fallback for the L2
>>>>>       cache.
>>>>>
>>>>>       What I tried to fix:
>>>>>       Jenkins is complaining about selenium tests (regressions.t) failing on
>>>>>       18.05, it is a succession of events and bugs that were not linked at
>>>>>       first glance.
>>>>>
>>>>>       Here are the different steps I went though:
>>>>>       - On bug 21426 we noticed that USE_MEMCACHED was not taken into
>>>>>       account. If set to "no" the default memcached config was defined in
>>>>>       the koha-config.xml file anyway
>>>>>       - A new regression selenium test was added on bug 21777 to catch the
>>>>>       presence of an audio alert on the circulation page
>>>>>       - Investigating the failing tests I noticed that koha-testing-docker
>>>>>       was not setting the memcached config on the 18.05 branches (I guess
>>>>>       the image has not been rebuilt yet)
>>>>>       search_utf8.t output "Warning: script running in daemon mode, without
>>>>>       recommended caching system (memcached)."
>>>>>       - I also find that [% Koha.Preference('AudioAlerts') %] did not return
>>>>>       the value set by the tests, but the value that the DB has before the
>>>>>       tests were launched
>>>>>       => It is a cache issue!
>>>>>       - ...but only when memcached is not set...
>>>>>       - Reading Koha::Cache->new we can notice that Cache::Memory is used
>>>>>       for the L2 cache when memcached is not defined in the config
>>>>>
>>>>>       And so we have the problem: If a value is set in the cache by a Plack
>>>>>       worker, it will not be available from another one, as the L2 cache is
>>>>>       not shared (!)
>>>>>
>>>>>       To recreate easily the problem you can:
>>>>>       - remove the memcached config
>>>>>       - edit intranet-bottom.inc and add
>>>>>       ===[% Koha.Preference('AudioAlerts') %]===
>>>>>       - restart plack
>>>>>       - Modify the value of AudioAlerts (using the UI)
>>>>>       - Reload the page (reload several times if the value is still correct,
>>>>>       it will depend on which worker will serve the request)
>>>>>
>>>>>       Solution:
>>>>>       I am considering removing Cache::Memory unless somebody else has a
>>>>>       better idea
>>>>>       Bug 21955 - Cache::Memory should not be used as L2 cache
>>>>>
>>>>>       Note that it should not affect a lot of people as everybody is
>>>>>       supposed to have memcached configured and working correctly!
>>>>>
>>>>>       Cheers,
>>>>>       Jonathan
>>>>>       _______________________________________________
>>>>>       Koha-devel mailing list
>>>>>       Koha-devel at lists.koha-community.org
>>>>>       <mailto:Koha-devel at 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/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Tom?s Cohen Arazi
>>>>>
>>>>> Theke Solutions (http://theke.io <http://theke.io/>)
>>>>> ?+54 9351 3513384
>>>>> GPG: B2F3C15F
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Koha-devel mailing list
>>>>> Koha-devel at 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/
>>>>>
>>>> --
>>>> Ere Maijala
>>>> Kansalliskirjasto / The National Library of Finland
>>>>
>>>> _______________________________________________
>>>> Koha-devel mailing list
>>>> Koha-devel at 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/
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>> --
>> Paul Poulain, Associ?-g?rant / co-owner
>> BibLibre, Services en logiciels libres pour les biblioth?ques
>> BibLibre, Open Source software and services for libraries
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/

--
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries

_______________________________________________
Koha-devel mailing list
Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181221/2614c7c8/attachment-0001.html>

From tomascohen at gmail.com  Wed Dec 26 15:50:06 2018
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Wed, 26 Dec 2018 11:50:06 -0300
Subject: [Koha-devel] LDAP config: update_password
Message-ID: <CABZfb=V0-LLuu-XgB_s_ZB-OEbSNaGXqOXKm6GR7xhAp3LASWg@mail.gmail.com>

Hi everyone, I was working on removing Koha::Patron->update_password, and
found out that Auth_with_ldap.pm has a routine that takes care of 'syncing'
the password from LDAP into the local DB.

Is anyone using that? I will keep the current behaviour, but was thinking
of filing a bug for its deprecation.

-- 
Tom?s Cohen Arazi
Theke Solutions (http://theke.io)
? +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181226/948b7e9e/attachment.html>

From kohanews at gmail.com  Thu Dec 27 04:10:09 2018
From: kohanews at gmail.com (kohanews)
Date: Wed, 26 Dec 2018 19:10:09 -0800
Subject: [Koha-devel] Koha Community Newsletter: December 2018
Message-ID: <8527dc84-a4bc-6e83-694f-910a589ed05b@gmail.com>

The Koha Community Newsletter for December 2018 is here:
https://koha-community.org/koha-community-newsletter-december-2018/

Many thanks to the folks who submitted articles and news to this month's 
newsletter.

Please feel free to email me with any corrections or suggestions.

-- 
Chad Roseburg
Editor, Koha Community Newsletter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181226/54d79eda/attachment.html>