[Koha] Slow Koha OPAC login process - a bug? Workaround exists

[Jonathan Druart]

I still do not recreate the problem.

^9999 dates are handled in our Koha::DateUtils module, take a look at:

223     # FIXME: see bug 13242 => no TZ for dates 'infinite'
224     if ( $dt->ymd !~ /^9999/ )
{
225         my $tz = $dateonly ? DateTime::TimeZone->new(name =>
'floating') : C4::Context->tz;
226         $dt->set_time_zone( $tz
);
227     }

Well there is a fixme, but basically it says that if the date is from 9999
we should use floating dates to avoid long processing when comparing dates.

Take a look at 12669, 13242 and
https://metacpan.org/pod/DateTime#Determining-the-Local-Time-Zone-Can-Be-Slow

I guess there is a use of DateTime using the tz somewhere in the code.

On Thu, 18 May 2017 at 17:22 Michael Kuhn <mik at adminkuhn.ch> wrote:

> Hi
>
> We're running a new host with Debian GNU/Linux 8 and Koha 16.11.04.
>
> On 13 April I first wrote that sometimea when trying to login into the
> Koha OPAC it takes more than 30 seconds until the login process finally
> comes to an end, while the process "opac-user.pl" was eating up 99% of
> the CPU.
>
> Some of you have kindly given my some hints but everything I tried was
> of no avail: logging mySQL slow queries, iotop, strace -c -p PID,
> tcpdump, checking logs (plack-error.log, opac-error.log etc etc),
> executing various time measurements of the Perl scripts, deactivating
> other programs (like Plack, EZproxy etc), enabling debugging for Plack,
> etc etc
>
> Eventually I executed "strace -t -s 1024 -p PID" and tried to understand
> the output. I doubt I did but some lines gave me the idea the problem
> was connected with the card expiry date. The user data were migrated
> from another ILS which contained a card expiry date of 9999-12-31 for
> every user - I manually changed this to 2030-12-31 via SQL and all of a
> sudden the login process was quick as experienced elsewhere. So the
> problem feels like SOLVED by a workaround, at least in our Koha instance!
>
> But meanwhile we have found out the following:
>
> 1. 9999-12-31 is a valid date accepted by MySQL (see
> https://dev.mysql.com/doc/refman/5.5/en/datetime.html)
>
> 2. The newly configured patron categories in our Koha instance all have
> an enrollment period of 999 months (strangely it's not possible to
> choose a higher number).
>
> 3. The migrated user data was imported via Koha menu "Tools > Patrons
> and circulation > Import patrons". NO ERROR occurred and all the data
> (including the date 9999-12-31) was correctly written into table
> "borrowers".
>
> 4. In Koha menu "Patrons > New patron" when a new patron is added with
> expiry date "31.12.9999" this is accepted WITHOUT ERROR. (the local Koha
> system preference "datetime" is set to "dd.mm.yyyy")
>
> 5. Trying to login into the Koha OPAC will immediately lead to described
> problem with the delayed login.
>
> 6. I tried step 4 on my own demo installation of Koha 16.11.00 with
> expiry date "31/12/9999" - there a dialogue appears saying "Invalid year
> entered in field dateexpiry". There is only a button "OK" - I clicked
> that and then saved the user data. This worked without further errors
> and the date can be found in field "borrowers.dateexpiry" as
> "9999-12-31". It seems rather strange to me that Koha should warn about
> an "invalid year" (whatever that means) but accepting it nonetheless.
> Trying to login with this user in the OPAC of my demo installation works
> quick as expected.
>
> To me the behavior (described in steps 1-5) feels like a bug because if
> date 9999-12-31 is accepted by the patron import tool and also by MySQL
> then it shouldn't be necessary to change that date. (But it seems this
> problem is only existing on our Koha instance)
>
> Also the behavior (described in step 6) feels at least like a minor bug
> because if Koha warns of an "invalid year" it should 1) be more explicit
> (what exactly is invalid about the year?) and especially it shouldn't
> allow to save that "invalid" year.
>
> What do you think of this?
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 <+41%2061%20261%2055%2061> · E mik at adminkuhn.ch ·
> W www.adminkuhn.ch
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>