| Time |
Nick |
Message |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 08:37 |
|
dwilliamson joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:59 |
|
aabbee joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:25 |
|
yboston joined #evergreen |
| 09:55 |
|
Christineb joined #evergreen |
| 10:03 |
* Dyrcona |
sighs at the junk searches that come in over Z39.50. |
| 10:06 |
* mmorgan |
is only somewhat comforted that it's not just us that gets those |
| 10:10 |
Dyrcona |
I would not have looked but I got a warning email from Nagios about resource use on that server. Of course, I didn't see the email until everything was "OK" again. |
| 10:11 |
Dyrcona |
Well, you put something on the Internet that anyone can use, and they will. :) |
| 10:11 |
Dyrcona |
Are keyword searches for ISBNs still known to be slow? |
| 10:13 |
csharp |
relevant: https://www.reddit.com/r/ProgrammerHumor/comments/bm9xrn/i_dont_really_hate_javascript_but_this/ |
| 10:13 |
csharp |
(not to the z39 thing, just to our current lives) |
| 10:14 |
mmorgan |
:) |
| 10:14 |
berick |
it's funny cuz it's true |
| 10:16 |
Dyrcona |
it's sad cuz it's true |
| 10:17 |
Dyrcona |
Is there a word for something that is said and funny at the same time? Maybe "piquant" from French. |
| 10:17 |
mmorgan |
Dyrcona: Not sure about isbn keyword searches being 'known to be slow', but some of our long running searches are indeed isbn keyword |
| 10:18 |
Dyrcona |
Related: While looking for a Lp bug about ISBN search being slow, I find a wishlist bug that makes me think, "Oh, Hell no. You really want to kill your server." |
| 10:18 |
Dyrcona |
mmorgan: Same here. I thought there was Lp bug on them being slow, but I can't find one. |
| 10:19 |
mmorgan |
Dyrcona: There was one for 2.12, since fixed, bug 1704396 |
| 10:19 |
pinesol |
Launchpad bug 1704396 in Evergreen 2.12 "Slowness for metarecord and one-hit searches in 2.12" [High,Fix released] https://launchpad.net/bugs/1704396 |
| 10:19 |
Dyrcona |
mmorgan: That's not what I was thinking of, but thanks for mentioning it. |
| 10:20 |
Dyrcona |
I'm seeing things like this repeated every 6 seconds or so in the gateway logs: ((eg.keyword = 078067670X or eg.keyword = 9780780676701) or eg.keyword = 9781622243075) |
| 10:21 |
Dyrcona |
And, that's probably the "worst" example. No way that's a quick search. |
| 10:23 |
mmorgan |
Dyrcona: Are those Z39.50? Those type of searches don't sound unusual for staff activities. |
| 10:24 |
Dyrcona |
They are z39.50. I'm looking at the logs on our z39.50 utility server and staff and the OPAC don't use it. |
| 10:24 |
mmorgan |
Ah. Ok. |
| 10:24 |
Dyrcona |
It's also a "SRU search string" in the logs. |
| 10:25 |
Dyrcona |
So, I'm 99% certain this was Z39.50. |
| 10:29 |
mmorgan |
Sounds right. |
| 10:30 |
|
jamesrf joined #evergreen |
| 10:40 |
Dyrcona |
I think they're trying to be malicious, now: ((((eg.keyword = 1551882 or eg.keyword = 2609520) or eg.keyword = 757284) or eg.keyword = 1488657) or eg.keyword = 2192639) |
| 11:18 |
|
mmorgan1 joined #evergreen |
| 11:57 |
|
sandbergja joined #evergreen |
| 12:33 |
|
jihpringle joined #evergreen |
| 12:50 |
|
yboston joined #evergreen |
| 12:58 |
|
sandbergja joined #evergreen |
| 13:00 |
|
_sandbergja joined #evergreen |
| 13:15 |
Dyrcona |
Whee! Seems that Z39.50 problem earlier wasn't a red herring. |
| 13:16 |
Dyrcona |
I see that the Commonwealth Catalog is sending us the search queries that I'm putting in, but we don't seem to be sending them any results back. |
| 13:30 |
Dyrcona |
Well, it took 2 seconds for the query to get results back through Supercat. |
| 13:31 |
Dyrcona |
So, maybe they aren't waiting that long? |
| 13:31 |
|
yboston joined #evergreen |
| 13:35 |
Dyrcona |
Oh, nice... opensrf.settings is not responding to SIGINT, so sending SIGTERM..... Maybe that was the problem? |
| 13:35 |
Dyrcona |
Err, that's backwards....TERM is sent first, then INT..... |
| 13:36 |
jeffdavis |
I've seen some weirdness with mis-ordering of Z39.50 search terms causing slow search queries, but that may be due to some local patch or customization |
| 13:36 |
* Dyrcona |
reboots the VM just for thoroughness-sake. |
| 13:36 |
Dyrcona |
Well, I'm beginning to suspect opensrf.settings was in some kind of limbo, but 2 seconds isn't terrible. |
| 13:39 |
Dyrcona |
I don't know how this Commonwealth Catalog is really supposed to work, but it only shows some of the results that I know we should return for some of these searches. |
| 13:40 |
Dyrcona |
It says we dont' have of The Spy by Paulo Coelho, but I know we have several. |
| 13:42 |
Dyrcona |
Oh, nice supercat says we ain't got 'ny if I do a keyword search. |
| 13:44 |
Dyrcona |
Ditto with a title/author search. |
| 13:46 |
Dyrcona |
Author search returns 4 records, but none of his novels. Just some essays in collections. |
| 13:47 |
Dyrcona |
I'm copying and pasting the SRU queries generated by simple2zoom from the logs. |
| 13:47 |
Dyrcona |
NOBLE doesn't seem to have this problem. :( |
| 13:48 |
|
stephengwills joined #evergreen |
| 13:56 |
Dyrcona |
mmorgan1: What release of Evergreen is NOBLE on? |
| 13:56 |
Dyrcona |
Something is definitely broken here, and the reboot didn't help. |
| 13:59 |
Dyrcona |
For some reason, we end up with 18 opensrf.settings drones running... |
| 14:00 |
Dyrcona |
min is 5 and max is 40 |
| 14:04 |
pinesol |
[evergreen|Bill Erickson] LP1823982 Vandelay Match Set new tree repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73ee4b0> |
| 14:15 |
berick |
sandbergja++ |
| 14:18 |
_sandbergja |
berick++ |
| 14:34 |
|
mmorgan joined #evergreen |
| 14:38 |
Dyrcona |
So, it looks like SRU is only search 505$r for both author and eg.author indexes, at least based on my limited sample. The OPAC gives me 198 results each for eg.author and author. |
| 14:39 |
Dyrcona |
I get just 4 results from SRU. |
| 14:56 |
Bmagic |
rhamby gmcharlt - what's the workflow for submitting a patch to migration-tools? |
| 15:01 |
Dyrcona |
I just emailed rhamby or gmcharlt and told them where the patch was, IIRC |
| 15:01 |
Bmagic |
I just did exactly that |
| 15:01 |
Bmagic |
:) |
| 15:02 |
berick |
if only the repo were in github *duck* |
| 15:02 |
berick |
i know gitlab does the same |
| 15:03 |
berick |
but seriously, per-repo issue trackers + merge requests will be nice |
| 15:06 |
Dyrcona |
IF we ever get there. |
| 15:09 |
|
yboston joined #evergreen |
| 15:37 |
kip |
Late Friday afternoon question I should have though to ask at the Evergreen conference. For reasons I'm happy to detail if needed, our library needs to have the email_notify field of the action.hold_request table set to true always. The table creation specifies a default of false. Aside from complicating upgrades, any reason I can't just change the table definition? |
| 15:39 |
Dyrcona |
kip: No reason. |
| 15:39 |
phasefx |
kip: not sure if setting the database default would help or not, if a full hold request object gets passed to the middle layer, that object likely has true or false already. |
| 15:40 |
kip |
We won't talk about my current inelegant hack of having a \watch loop running in a psql session updating that field endlessly which has been working but is silly. :) |
| 15:40 |
phasefx |
could use a trigger |
| 15:40 |
Dyrcona |
Well, yeah....what phasefx said. |
| 15:41 |
* Dyrcona |
would just modify the holds code. |
| 15:41 |
kip |
Okay, I'll give it a shot and watch for issues. And modifying the holds code is certainly on the table, just haven't freed up the focus to dive in. |
| 15:41 |
* phasefx |
would be tempted. Trigger has the benefit of better surviving upgrades |
| 15:42 |
phasefx |
but ultimately, I would at least want to change the end-user visible UI so that they're not given an option that won't mean anything |
| 15:44 |
kip |
We don't give our patrons the stock UI, so that's not an issue for us. |
| 15:45 |
phasefx |
cool deal |
| 15:45 |
Dyrcona |
Actually, doing it in the template would probably be best. Set the field to hidden and hard code the on value. |
| 15:46 |
Dyrcona |
We have some customization there for similar but different reasons/purposes. |
| 15:47 |
kip |
Basically the email is generated on our end to deal with hold slip notices being shot to a printer tee'd with a script that actually honors our real email_notify value in the UI we present to the public. |
| 15:49 |
|
Glen__ joined #evergreen |
| 15:52 |
* mmorgan |
returns to desk after long absence. Dyrcona: NOBLE is on 3.1.8 |
| 15:55 |
Dyrcona |
mmorgan: Thanks! |
| 15:55 |
Dyrcona |
Our supercat is acting odd, but I think it's just us. |
| 15:56 |
mmorgan |
Odd in that it's not finding everything it should? |
| 15:57 |
Dyrcona |
Right. For author it seems to only look at 505 fields, possibly for titles, too. |
| 15:58 |
Dyrcona |
From what I can tell, it should be using the author class as the OPAC, but I'll do some more digging into the actual code later. |
| 16:26 |
|
BAMkubasa joined #evergreen |
| 16:29 |
BAMkubasa |
Is there a place in the database where you can do stats on activity through SIP connections? Looking at actor.usr_activity you can see when the SIP account connected (etype 7) but not much else |
| 16:31 |
rhamby_ |
that's about it, you'll need to look at log files for more |
| 16:38 |
berick |
BAMkubasa: you can assign specific activity types per SIP login account |
| 16:39 |
jeff |
BAMkubasa: can you tell us what you're trying to accomplish? |
| 16:57 |
BAMkubasa |
trying to see how many users make use of a service that has a specific SIP login |
| 16:57 |
BAMkubasa |
and trying to see if I can get anything about the patron permission groups of the users |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:05 |
|
mmorgan left #evergreen |
| 17:06 |
|
yboston joined #evergreen |
| 18:01 |
|
jamesrf joined #evergreen |
| 19:56 |
|
sandbergja joined #evergreen |
| 22:05 |
|
sandbergja joined #evergreen |
| 22:33 |
|
sandbergja joined #evergreen |
| 23:44 |
|
sandbergja joined #evergreen |
