Calling "next" from within a "try" block results in a memory leak,
presumably because "try" is a tangled nest of subs and evals.
Replacing the "try" with a good ol' "eval" avoids the leak.
This particular leak in the fine generator is onerous when the fine
generator is run often (e.g. every 15 mins), which means circs that
have already been processed for the day are re-analzyed over and over,
causing the code to continue early (next) to the next loop iteration
for large numbers of circs. It also happens when a circs are skipped
because they have no fine interval, rate, or max fine.
You know this is happening because you will see something like this in
the storage stderr log:
Exiting eval via next at
/usr/local/share/perl/5.10.1/OpenILS/Application/Storage/Publisher/action.pm
line 820.
Exiting subroutine via next at
/usr/local/share/perl/5.10.1/OpenILS/Application/Storage/Publisher/action.pm
line 820.
This patch does not avoid the "exiting eval via next" warning, since
we're still next'ing out of the eval. It just avoids the memory leak
(and the "Exiting subroutine" warning). More extensive refactoring is
needed to to completely remove the second warning.
Signed-off-by: Bill Erickson <email address hidden>
Signed-off-by: Mike Rylander <email address hidden>
When looking for authority records to control a bib field, we currently
search using exactly, and only, the subfield that was clicked. This
commit changes that so that the full field up to and including the clicked
subfield is used in the simple authority heading search we perform to find
the best-match (pivot) authority record.
TPAC - set autofocus to user input when placing holds in staff client
When placing holds in TPAC via the staff client, the focus had been on the
basic search field above. Change this to have autofocus on the input field
for the hold user by default.
This can potentially save staff from having to perform an extra click to
select the input field. Now they can immediately begin entering the barcode
of the user they plan to create a hold on behalf of.
Signed-off-by: Mike Rylander <email address hidden>
33b4964...
by
Lebbeous Fogle-Weekley <email address hidden>
Acq: Be fuzzy about case when retrieving EDI documents
The edi_fetcher relies on a routine in OpenILS::Acq::EDI to, among
other things, try to avoid fetching the same EDI document multiple times
when many rows in acq.edi_account refer to the same host and login
credentials.
Since in practice most vendors seem to run FTP servers for EDI on
Windows, not UNIX, and pathnames are therefore case-insensitive, that
test for other occurrences ought also to be case-insensitive.
If I were to look at this as a purist, I could argue that vendor servers
might sometimes by run on UNIX, and that for some reason it is possible
that different vendor-to-buyer EDI documents (order responses or
invoices) could have pathnames that differ only in the case of some
characters. But that seems wildly unlikely. If anyone does take this
possibility seriously, perhaps acq.edi_account needs a Boolean column to
indicate the remote host's case [in]sensitivity.
