retarget.all option when checking in an item times out

[Steve Callender]

Tested on 2.3.3

When checking in an item using the retarget all option for holds, if there happens to be quite a large amount of holds to process, the check-in even can time out causing an error on check-in.

We need to somehow avoid long-running calls while a transaction is open to another service.

In logs, I have seen a hold take over 6 seconds to process after the check-in process has started,

2013-06-08 12:42:01 open-ils.storage: [INFO:18173:action.pm] #011Processing of hold 1953305 complete.
2013-06-08 12:42:01 open-ils.storage: [INFO:18173:Transport.pm] Message processing duration: 6.395

After which the check-in process continues and fails due to timing out,

2013-06-08 12:42:01 open-ils.circ: [ERR :22263:EX.pm] Exception: OpenSRF::DomainObject::oilsMethodException 2013-06-08T12:42:01 OpenILS::Utils::CStoreEditor /usr/local/share/perl/5.10.1/OpenILS/Utils/CStoreEditor.pm:453 <400> No active transaction -- required for UPDATE
2013-06-08 12:42:01 open-ils.circ: [INFO:22263:CStoreEditor.pm] request returned no data : open-ils.cstore.direct.asset.copy.update
2013-06-08 12:42:01 open-ils.circ: [INFO:22263:Circulate.pm] circulator: pushing event DATABASE_QUERY_FAILED
2013-06-08 12:42:01 open-ils.circ: [INFO:22263:Circulate.pm] circulator: BAILING OUT

Maybe we need to first check-in the item completely and secondly do the hold targeting work?

Steve

[Ben Shum (bshum)]

Confirmed for us too. We noticed this issue after our upgrade to master/2.2 last year. In our case, the issue manifested largely due to differences in running virtual machine bricks instead of bare-metal and the fractions longer it took to perform the hold retargeting that led to all the errors. Though we also saw it happen with very popular materials that had lots of holds to go through.

[Jason Stephenson (jstephenson)]

We run on bare metal and we see it sometimes, too, with very popular titles.

[Jason Stephenson (jstephenson)]

We have gotten more and more reports of this problem since recent changes to best holds matching went in. It happens with retarget and not just retarget.all for our members. I am going to take a stab at backgrounding the retarget holds calls, doing the checkin and waiting for the retarget to finish in separate transactions.

[Jason Stephenson (jstephenson)]

Um, never mind. I went down that rabbit hole and lost my head to the Red Queen.

[Michele Morgan (mmorgan)]

Setting the status of this back to New due to the release of the refactored hold targeter in 2.12 (bug 1596595). Can anyone confirm this is still a problem with the new targeter in place?