retarget.all option when checking in an item times out
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
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:
2013-06-08 12:42:01 open-ils.storage: [INFO:18173:
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:
2013-06-08 12:42:01 open-ils.circ: [INFO:22263:
2013-06-08 12:42:01 open-ils.circ: [INFO:22263:
2013-06-08 12:42:01 open-ils.circ: [INFO:22263:
Maybe we need to first check-in the item completely and secondly do the hold targeting work?
Steve
no longer affects: | evergreen/2.2 |
no longer affects: | evergreen/2.3 |
no longer affects: | evergreen/2.4 |
Changed in evergreen: | |
status: | New → Won't Fix |
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.