Checkin age based hold protected item may not fill fillable holds

That pastebin is no longer valid

This appears to still be a problem for many of our locations that are using Age-based hold protection in our large consortium.

This is still an issue in EG 3.3. When age hold protect is applied and there are over 100 holds that know about the item, it only goes through the first 100 leaving anything outside of that range, including holds that do pass the age hold protection rule, to not be checked and ignored.

Does it work to increase the limit on the number of holds that will be evaluated?

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Holds.pm;hb=1711f0fe3fbb09f56e2f4befd13de076fc621bb3#l3166

Changing the 100 to something higher? Or does that cause the process to take too long?

Josh

Hi Josh,

Increasing the limit will probably lead to timeouts. However, I have another possible option:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1508208-age_protect_hold_capture

From the commit message:

When hold capture is attempted, we look at (currently) the first 100
holds ordered by Best Hold Sort Selection Order. If a very long list
of holds are targetting an age-protected item then op capture may not
have a chance to see a viable hold for that copy.

This commit attempts to take into account the age protection currently
set for the copy by restricting the holds to just those where the
hold-copy-map proximity is less than or equal to the maximum proximity
allowed by the age protection. This works now because we store the
hold proximity in the hold copy map, where we did not before.

Being based on the hold-copy-map proximity, which is calculated
proximity, means this is an approximation and the final hold capture
logic may still reject some holds for the copy. Likewise, this does
not entirely eliminate the possibility that there may be a better hold
to capture the copy for if the in-range set of holds is very, very
long, but this should allow hold capture to proceed if even
imperfectly.

If no age protection is set for the copy, the current behavior
(looking at all holds) is maintained.

I don't have a good means to test this at the moment, but to process 100 holds it takes 10 seconds (marking it in the logs from the very first retarget call to the last), and in the example I was looking at, there was over 200 total holds that had the item in it's sights, so I would imagine adding on at least another 10 seconds, which would be quite a long time for a check-in. I think the local holds should be at the very list sorted to the top of the list and be part of the first 100 checked.

I've force-pushed a rebased and fixed branch to the same location.

Thanks Mike! I've added my sign off and an extra commit with a live_t test. It's a drastic speed improvement on my test system: from 17 seconds to 1 second.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/lp-1508208-age_protect_hold_capture

Just wanted to mention that I also manually tested with some retarget checkin modifiers and things also seemed fast.

This fix made it into Master for 3.6.1 and 3.5.2. I'm updating the status to Fix Released but am unable to update the Milestones.