| Time |
Nick |
Message |
| 00:04 |
|
sandbergja joined #evergreen |
| 00:18 |
|
jamesrf joined #evergreen |
| 01:27 |
|
jamesrf joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-28T04:58:20,153401959-0400 -0> |
| 07:01 |
|
agoben joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 08:03 |
|
littlet joined #evergreen |
| 08:06 |
|
bos20k joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:53 |
|
aabbee joined #evergreen |
| 09:40 |
bshum |
FYI, to make some room on Lupin, I'm going to be dumping the rel_2_12 bzr checkout for LP translation sync on that series. Since that series is EOL, I don't think it'll affect anything too much. |
| 09:42 |
bshum |
I think I'll also get rid of rel_3_0 bzr i18n sync too. Since 3.0 is also past development |
| 09:44 |
bshum |
Unrelated, being able to use Powershell on a Windows client and SSH to Linux servers is pretty awesome :) |
| 09:46 |
jeff |
For those using the web staff client with RFID pads with 3M/Bibliotheca style software keyboard wedges that target a window by title, are you modifying templates so that the window title does not include patron name, are you launching the staff client in an "application" window in Chrome, or have you found another approach? |
| 09:59 |
pinesol |
[evergreen|Bill Erickson] Coerce numbers for bib IDs in Angular staff catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1522d95> |
| 09:59 |
|
sandbergja joined #evergreen |
| 11:07 |
|
jihpringle joined #evergreen |
| 11:37 |
|
khuckins joined #evergreen |
| 11:39 |
jeff |
Never mind that question, I guess. Poor assumption on my part. |
| 11:39 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.2.5 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=844bd68> |
| 11:39 |
jeff |
It doesn't seem to get picky about the window title changing. |
| 11:40 |
jeff |
Which is good! |
| 11:47 |
pinesol |
[evergreen|Dan Wells] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d208baf> |
| 11:47 |
pinesol |
[evergreen|Dan Wells] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb7cfe4> |
| 11:52 |
|
littlet joined #evergreen |
| 12:08 |
|
mmorgan1 joined #evergreen |
| 12:20 |
|
sandbergja joined #evergreen |
| 12:48 |
jeff |
picking a Z39.50 source that supports Keyword and one that does not, and then submitting a search with only a keyword specified... leads to a failure along the lines of "Can't call method "option" on an undefined value at /usr/local/share/perl/5.24.1/OpenILS/Application/Search/Z3950.pm line 437." |
| 12:50 |
jeff |
Interestingly enough, perhaps due to a local logging quirk, I'm only seeing the error appear in Apache logs. |
| 13:08 |
|
wsmoak joined #evergreen |
| 13:55 |
bshum |
berick: Some feedback on the remoteip commit for the ansible installer |
| 13:55 |
bshum |
It looks like we need to add a step to do a2enmod remoteip as well |
| 13:56 |
bshum |
Otherwise, just editing the config file leads to a failed ansible run due to not being able to start apache due to the config change |
| 13:56 |
bshum |
This is from a test run I'm doing on 18.04, not sure if the same issue presents in 16.04 but the commit didn't seem too different |
| 13:57 |
bshum |
I'll file a bug and put up a pullrequest later if you don't get to fixing it quicker :) |
| 14:13 |
berick |
bshum: oh, hm |
| 14:14 |
berick |
good catch, thanks bshum |
| 14:15 |
|
stephengwills joined #evergreen |
| 14:16 |
berick |
bshum: i'll push a patch |
| 14:16 |
berick |
(unless you're already typing) |
| 14:18 |
bshum |
berick: Nope, busy with a few other loose ends |
| 14:19 |
* berick |
nods |
| 14:19 |
* berick |
patches |
| 14:19 |
bshum |
I just figured I would kick off the ansible install and let it do its thing :) |
| 14:19 |
bshum |
berick++ |
| 14:20 |
berick |
done |
| 14:20 |
berick |
funny, I just used it the other day on ub 16.04. must have manually enabled in the heat of battle and forgotten to go back and patch it. |
| 14:45 |
|
berick joined #evergreen |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:27 |
|
khuckins joined #evergreen |
| 15:30 |
|
stephengwills left #evergreen |
| 15:40 |
mmorgan |
We have a library with an automated materials handler that will sometimes go offline when checking in some new or popular items. I'm fairly sure it's because of bug 1803768. Has anyone else encountered a similar problem? |
| 15:40 |
pinesol |
Launchpad bug 1803768 in Evergreen "Checkins for not holdable or age protected items on Bib Records with many holds can take a long time" [Medium,New] https://launchpad.net/bugs/1803768 |
| 15:41 |
jeff |
we have not, because we dont do much/any age hold protection at our main branch (the only one with SIP-based checkin devices / AMH). |
| 15:42 |
jeff |
but i think you're likely on the right track. |
| 15:43 |
jeff |
we have encountered issues with checkin of age hold protected items at remote locations where there are a large number of holds on the title, none/few of which can be fulfilled by the item. |
| 15:45 |
jeff |
what happens when you check one of the problematic items in at a staff client instead of via SIP? |
| 15:46 |
mmorgan |
They can check the items in via the staff client, but I expect it takes a long time. Logged durations can be as much as 7 - 8 seconds for the most extreme cases. |
| 15:46 |
* jeff |
nods |
| 15:47 |
bshum |
Back in the day... we had an RFID AMH that one of the libraries wanted setup |
| 15:47 |
bshum |
It would toss most things into exception bin due to the time it took just to do regular hold processing too |
| 15:47 |
jeff |
it might be worth determining if the AMH has a setting for how long it waits for a SIP response. |
| 15:47 |
bshum |
If there were a lot of holds on it |
| 15:47 |
mmorgan |
This library also has "Express" items, that are not holdable at all, but still look for 100 possible holds to fill at checkin. |
| 15:48 |
bshum |
We ended up cheating by setting up the SIP server to point at a special Evergreen app server where we customized the hold checked to only look at 10 results or something |
| 15:48 |
bshum |
To speed up the lookup |
| 15:48 |
bshum |
Then the AMH guys reset the gears to slow down their machine slightly too |
| 15:48 |
bshum |
So that they could be more in sync |
| 15:49 |
mmorgan |
The AMH does have a timeout setting, which has been increased in the past. Is there any harm in extending a timeout to something like 8 seconds, if it's possible? |
| 15:50 |
jeff |
one thing we've talked about in the past has been "should age hold protected / non-holdable items be added to action.hold_copy_map?" |
| 15:50 |
mmorgan |
Do they get added to the hold_copy_map now? |
| 15:50 |
bshum |
mmorgan: If the AMH belt is set to pass items more quickly than the timeout, I expect the item would end up in the wrong bin before it could receive a properly reply. |
| 15:51 |
bshum |
But uh... yeah, my info knowledge is many years out of date now |
| 15:51 |
jeff |
mmorgan: i believe that they do, yes. |
| 15:51 |
bshum |
So I'll be quiet :) |
| 15:52 |
jeff |
mmorgan: increasing the timeout on the SIP client means in theory that it will take longer to give up on the SIP server in cases of actual outage. depends on your AMH, and how patrons interact with it (if at all), but in this scenario increasing the timeout is likely a good option for a workaround. |
| 15:53 |
jeff |
mmorgan: empirical testing may give most accurate results. :-) |
| 15:54 |
* jeff |
breaks user editor changes into logical commits and bugs |
| 15:55 |
mmorgan |
jeff: We can request an increase in the timeout to see if that helps. I'd prefer to fix the bug, though ;-) |
| 15:57 |
mmorgan |
So if nonholdable items weren't in the hold_copy_map, would that prevent evergreen from polling through 100 holds that the item can't fill? Or would it still do that? |
| 15:59 |
jeff |
i believe the ahcm table is what is consulted at checkin time for opportunistic hold capture |
| 16:00 |
jeff |
it may also be used for "copy needed for hold" blocking renewal, and/or for circ rules that pay attention to copy/hold ratios... |
| 16:01 |
jeff |
if there's too much that relies on ahcm in that case, then perhaps an additional column in ahcm that lets us skip "unlikely to be eligible" copies could help. |
| 16:02 |
jeff |
it's been a while since i looked at this, but i should probably look at it again. |
| 16:03 |
* mmorgan |
would be interested in any ideas to fix bug 1803768 |
| 16:03 |
pinesol |
Launchpad bug 1803768 in Evergreen "Checkins for not holdable or age protected items on Bib Records with many holds can take a long time" [Medium,New] https://launchpad.net/bugs/1803768 |
| 16:12 |
* mmorgan |
is looking at the hold_copy_map, an age protected item is in the hold_copy_map for every one of the 415 holds on the bib, but my nonholdable item on the same title is only in the hold_copy_map once. |
| 16:15 |
jeff |
okay, that sounds familiar. |
| 16:15 |
mmorgan |
Yet on checkin, 100 holds still get considered to capture the item. |
| 16:15 |
jeff |
for your nonholdable item? |
| 16:15 |
mmorgan |
Yes, the nonholdable one. |
| 16:16 |
jeff |
what makes it nonholdable? asset.copy.holdable = false or asset.copy_location.holdable = false or something else? |
| 16:16 |
mmorgan |
asset.copy.holdable = false |
| 16:16 |
jeff |
and is there something unique about the one hold that does have an ahcm for said "unholdable" copy? |
| 16:17 |
jeff |
is it an unusual type of hold, or is it suspended/cancelled/etc? |
| 16:18 |
mmorgan |
Not that I can see, it's hold_type T, pickup location is a different org unit than the copy.circ_lib |
| 16:19 |
mmorgan |
Oh, it's frozen. |
| 16:21 |
* mmorgan |
isn't sure what that means. |
| 16:21 |
jeff |
frozen holds don't have their copy map updated by the targeter, iirc. |
| 16:22 |
jeff |
so it may have been a hold placed long ago before the copy was set to holdable=false. |
| 16:24 |
jeff |
mmorgan: you're looking at logs to see that it's checking holds for the item, yes? are the log entries along the lines of "circulator: checking if hold $holdid is permitted for copy $bc"? |
| 16:24 |
mmorgan |
jeff: Yes, those are the log entries I'm looking at. |
| 16:27 |
jeff |
oh interesting. |
| 16:28 |
jeff |
so, for your non-holdable item. checking it in checks a large number of holds, and it only appears once in the action.hold_copy_map table, and that's for the frozen hold? |
| 16:28 |
mmorgan |
Yes, exactly. |
| 16:29 |
jeff |
i'm wondering what would happen if you did something that caused that row to no longer be present in action.hold_copy_map. say, deleting it manually, or attempting to force retarget the hold (or maybe thawing then freezing the hold) |
| 16:30 |
mmorgan |
Hold that thought. I'm going to check the copy auditor table to make sure. |
| 16:30 |
jeff |
oh, to test the theory that the frozen hold was placed (or last targeted) before the copy was made non-holdable? |
| 16:31 |
mmorgan |
Well, to make sure that the item was actually nonholdable when these transactions happened. |
| 16:31 |
jeff |
ah. |
| 16:31 |
mmorgan |
Interestingly, the frozen hold was placed before the copy was made active. Can't say when the hold was frozen, though. |
| 16:33 |
jeff |
ah, right. prev_check_time gets nulled when frozen, i think. |
| 16:35 |
jeff |
are you in a position to be able to do something that causes that copy to no longer appear in action.hold_copy_map, and then check the item in again to see if it's still checked against a bunch of holds? |
| 16:35 |
mmorgan |
Yes, prev_check_time is null for the hold. |
| 16:36 |
mmorgan |
jeff: not with that particular item. |
| 16:38 |
jeff |
are you able to create a fake copy on a title with many holds, make the fake copy holdable=false, and check that item in? |
| 16:39 |
jeff |
bonus points if you want to test it with and without a single frozen hold that has that copy in its copy map... bit of work to set up, i know. |
| 16:40 |
jeff |
i could probably test this theory here. |
| 16:40 |
mmorgan |
Item was created as a holdable on order item. Item was changed to not holdable at 12:53, and checked in at 14:17 the same day. So it likely appeared in the hold_copy_map for many holds at that point. |
| 16:40 |
mmorgan |
So, that kind of blows the theory :) |
| 16:42 |
* mmorgan |
can check more recent logs for the same item to see how many holds get tested. |
| 16:44 |
jeff |
ah, okay. i think i originally thought the logs in question were a bit more contemporary. i think i understand now. |
| 16:49 |
mmorgan |
jeff: TBH, I wasn't as mindful as I should have been of the age of the logs. A checkin of that item from yesterday does not show multiple holds being checked, not even the frozen one in the hold copy map. |
| 16:50 |
mmorgan |
jeff++ |
| 16:50 |
mmorgan |
Thanks for helping me think this through. I looks like they actually have the problem with just newly cataloged items. |
| 16:51 |
mmorgan |
Lots of entries in the hold_copy_map that are no longer relevant. Maybe we can work that angle. |
| 16:52 |
mmorgan |
Sorry to take up your time! |
| 16:52 |
mmorgan |
jeff++ |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:03 |
jeff |
well, i'm glad to have the theory regarding non-holdable copies disproven. |
| 17:04 |
mmorgan |
Me too! |
| 17:04 |
jeff |
the age hold protected copies are still a bit of an issue. will have to revisit. |
| 17:04 |
jeff |
mmorgan++ |
| 17:05 |
mmorgan |
Yes, age hold protected copies will continue to delay checkins. I'll add a comment to the bug. |
| 17:06 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.1.11 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=12f53dd> |
| 17:08 |
* jeff |
attempts to cut patron editor load time from 5 seconds to 1 second |
| 17:08 |
mmorgan |
jeff++ |
| 17:09 |
|
mmorgan left #evergreen |
| 17:31 |
jonadab |
jeff++ indeed |
| 19:55 |
jeff |
Request Time in seconds: 3.891619 |
| 19:56 |
jeff |
Request Time in seconds: 0.094244 |
| 19:56 |
jeff |
(improvement by caching open-ils.circ.stat_cat.actor.retrieve.all) |
| 20:08 |
jeff |
(mostly because we have a dozen user stat cats) |
| 20:22 |
bshum |
jeff++ # fancy |
| 20:23 |
jeff |
now we have just the normal caching problems. |
| 20:31 |
|
jamesrf joined #evergreen |
| 21:47 |
|
stephengwills joined #evergreen |
| 21:56 |
|
sandbergja joined #evergreen |
