Author: John Merriam
Revision Date: 2019-06-07 15:31:59 UTC

LP#1824184: Change potentially slow log statements to subroutines

The OpenSRF code was searched for potentially slow logging statements at
log level info or above. We then changed those logging statements to be
delayed execution subroutines. This is in reaction to LP1823338 where a
slow debug logging statement was slowing down SIP checkins even though
debug logging was not turned on.

Here is some pseudocode that shows what is being done here:

$log->debug("Some text " . $some->slow_method);

would be changed to:

$log->debug(sub{return "Some text " . $some->slow_method });

With this change, an unnamed sub is passed to the OpenSRF logger module
and it will not be executed unless the global logging level is set to
debug or higher (the slow_method will not be called unless it is needed
for that logging level).

********
If/when this is committed, please use delayed execution subroutines for
any logging statements that could be slow in the future. It is recommend
that any logging statements that do not consist entirely of quoted text
and/or already available scalar variables use delayed execution
subroutines.
********

Testing notes
-------------
[1] This patch reduced the duration of open-ils.storage.actor.user.total_owed
    calls on a test system from an average of 0.13 seconds to an overage
    of 0.009 seconds.
[2] It didn't materially affect the duration of calls to
    open-ils.actor.user.opac.vital_stats.
[3] This make sense: open-ils.storage has far more generated methods
    than open-ils.actor.
[4] There are enough instances in Evergreen of using method_lookup to find
    routines in open-ils.storage that the speed improvement may well be
    perceptible to humans, not just SIP sorters.

Signed-off-by: John Merriam <jmerriam@biblio.org>
Signed-off-by: Galen Charlton <gmc@equinoxinitiative.org>

Author: dbs
Revision Date: 2011-05-09 17:10:19 UTC

Inline TestObject for net_obj_test.py as well

Signed-off-by: Dan Scott <dan@coffeecode.net>

Author: gmc
Revision Date: 2011-03-18 02:44:54 UTC

specify use of the utf8 I/O layer

Solves problem where invoking a method via osrf_http_translator
resulted in an exception thrown by FreezeThaw if any of the characters
in the message are non-ASCII *and* not in the Latin-1 character
set. Oddly, if Evergreen been originally developed in Georgia the
country, not Georgia the state, the bug would have been apparent much earlier.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>