| 12:46 |
Dyrcona |
ugh. While writing the POD for my race condition inducing script, I discover a few changes that I should make to it because a couple of local expectations/exceptions are baked in. |
| 12:47 |
Dyrcona |
I have to get the event_definition ids for the autorenew events via a search: easy enough. |
| 12:48 |
Dyrcona |
Looks like the main query can also lose the join on actor.usr and just use the circulation's circ_lib instead of the usr's home_ou. |
| 12:54 |
Dyrcona |
I'm adding this to the test-scripts because it can be used to test the patch. I'm not sure it's exactly the right place but i couldn't think of anywhere else to put it. |
| 12:55 |
justdoglet |
Possibly slightly OT, and let me know if so -- does anyone use Apache mod_security in front of EG? If so, are there any particular resources that helped you find/create rules for EG? Like lots of folks, we have issues with bots. We're evaluating possible solutions, and one is compatible with mod_security rulesets, so it seemed like a good bet to ask if anyone else is using it. |
| 12:56 |
Dyrcona |
We don't mind off topic here, and that sound topical to me. We don't use mod_security. We're blocking bots on Evergreen with nginx tricks. Bmagic could explain it better than I can. |
| 12:57 |
justdoglet |
Awesome. Thank you, Dyrcona! |
| 13:03 |
* Dyrcona |
needs to switch gears for a moment and look into an acquisitions fund source question. |
| 13:03 |
justdoglet |
Yes, of course. Don't mind me. :) |
| 13:14 |
|
jihpringle joined #evergreen |
| 13:55 |
* Dyrcona |
sets up a test of the final script via at. |
| 15:20 |
Bmagic |
justdoglet: one minute, I'm finding a link for you |
| 15:21 |
Bmagic |
I'm away from my computer this week, attending a conference, but I happend to see IRC just now |
| 15:23 |
justdoglet |
Thank you! I appreciate it. |
| 10:55 |
Dyrcona |
How are you running queries in the database? |
| 10:56 |
mantis1 |
just through PGAdmin but we sometimes do it via terminal - those are mostly for queries that take a longer time or for the update queries |
| 10:58 |
Dyrcona |
You should be able to type that into PgAdmin as part of your SQL. I wouldn't do it during normal business hours. |
| 10:59 |
mantis1 |
I was running everything on a test server but the error I posted earlier still showed up |
| 10:59 |
Dyrcona |
PgAdmin should be able to show you the triggers on a table. It has been a while since I used it. |
| 10:59 |
Dyrcona |
What Pg version? |
| 10:59 |
mantis1 |
4 |
| 12:09 |
pinesol |
csharp_: go with Jersey Mike's |
| 12:17 |
Dyrcona |
mantis1++ Glad you worked it out. |
| 12:26 |
Dyrcona |
hm.. where did I leave that query to see how much space a table takes up? |
| 12:30 |
Dyrcona |
csharp_: After running your script on my test database, my actor.usr_message table was 363 MB. Doing a vacuum full on it dropped it to 193 MB. You could just add the vacuum full after your delete. |
| 12:30 |
Dyrcona |
Think I'll drop the rule and deleted the deleted rows to see what happens. |
| 12:32 |
Dyrcona |
Now it's only 32 MB. :) |
| 12:33 |
Dyrcona |
Not gonna do that in production, but there it is. |
| 11:30 |
Dyrcona |
jeff: Going back to this conversation from Thursday http://irc.evergreen-ils.org/evergreen/2025-05-22#i_578526 is there a Launchpad bug for that? |
| 11:32 |
|
jihpringle joined #evergreen |
| 12:03 |
pinesol |
News from commits: LP#2106667: Remove Fedora Makefile.install target <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1279b152400d29c1eec4bac38f437242a1c05779> |
| 12:05 |
Dyrcona |
Grr. I wonder if this is another case of PostgreSQL versions changing results. I'm getting test failures with make livecheck: live_t/03-overdue_circ.t, live_t/04-overdue_with_closed_dates.t, and live_t/05-pay_bills.t. |
| 12:20 |
Dyrcona |
Has anything changed in billing since last week? |
| 12:38 |
csharp_ |
sandbergja++ |
| 12:42 |
Dyrcona |
Those 3 tests consistently fail for me on a test vm communicating with a Pg 17 database, but I don't recall them failing last week. |
| 12:54 |
sandbergja |
Dyrcona: those tests are passing for me with pg 17 |
| 12:55 |
Dyrcona |
Well, I guess I'll push the Lp 2111716 branch. I don't think the test failures that I'm seeing have anything to do with it. |
| 12:55 |
pinesol |
Launchpad bug 2111716 in Evergreen "Move t/lp2110251-circ-renewal-field.t to live tests" [Low,Confirmed] https://launchpad.net/bugs/2111716 - Assigned to Jason Stephenson (jstephenson) |
| 12:55 |
sandbergja |
with make livecheck at least, I can reload the db and retry with prove |
| 12:55 |
sandbergja |
Dyrcona++ |
| 12:56 |
Dyrcona |
Well, they're failing for me, unless I'm not looking at the correct database for some reason, but I even did eg_db_config with the options to set the values in opensrf.xml. |
| 12:57 |
Dyrcona |
I don't recall them failing last week, so I don't know what's up. |
| 12:58 |
sandbergja |
yeah, it's interesting that it's just those 3 |
| 12:58 |
csharp_ |
@who moved Dyrcona's server's cheese? |
| 12:58 |
pinesol |
sleary moved Dyrcona's server's cheese. |
| 13:03 |
pinesol |
News from commits: LP2111716: move t/lp2110251-circ-renewal-field.t to live tests <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b3785515caede05b6286148ea28c88d4f54820ff> |
| 13:11 |
Dyrcona |
Man, it is hard causing a race condition. |
| 14:04 |
|
jihpringle joined #evergreen |
| 14:25 |
mantis1 |
when using the marc stream importer, if one record fails, do the rest fail? |
| 14:44 |
Dyrcona |
mantis1: I have no idea. It uses vandelay. That's all I can say. |
| 15:06 |
mmorgan |
mantis1: Just checked with a colleague more familiar with loading records than I am, hoping for a quick answer. Not an answer, but a suspicion that if one record fails, the rest will not load. Hoping someone else has a better answer. |
| 15:10 |
Dyrcona |
So, I can reproduce the race condition that causes the ACTION_CIRCULATION_NOT_FOUND response to patrons. I got it for 154 autorenewals in my test. Once I adjusted my script a little it became really easy to force it. |
| 15:13 |
mantis1 |
mmorgan: ah that's too bad if that's the case |
| 15:18 |
* Dyrcona |
has to wait for 4:30 to do another test run with the patch applied. |
| 15:19 |
Dyrcona |
I suppose I could run the a/t runner manually.... |
| 15:35 |
Dyrcona |
I also can't seem to get those tests to pass on my other test system today. |
| 15:47 |
sandbergja |
what specific failures do you get Dyrcona? |
| 15:49 |
Dyrcona |
# Failed test 'Thirteen bills associated with circulation' |
| 15:49 |
Dyrcona |
# at live_t/03-overdue_circ.t line 201. |
| 15:49 |
Dyrcona |
# got: '12' |
| 15:49 |
Dyrcona |
# expected: '13' |
| 15:50 |
Dyrcona |
# Failed test 'Twelve bills associated with circulation (instead of 13, thanks to closed date)' |
| 15:50 |
Dyrcona |
# at live_t/04-overdue_with_closed_dates.t line 253. |
| 15:50 |
Dyrcona |
# got: '11' |
| 15:50 |
Dyrcona |
# expected: '12' |
| 15:50 |
Dyrcona |
# Failed test 'Both transactions combined have a balance owed of 1.25' |
| 15:50 |
Dyrcona |
# at live_t/05-pay_bills.t line 102. |
| 15:50 |
Dyrcona |
# got: '1.15' |
| 15:50 |
Dyrcona |
# expected: '1.25' |
| 15:51 |
Dyrcona |
That last one seems familiar. I think I've seen that before. |
| 15:56 |
Dyrcona |
i wonder if it's because the timezone is set to UTC? |
| 16:01 |
Dyrcona |
I'll bet that's it. I've changed the timezone and I'll runt the tests again. I bet it is happening because the db server and test vm don't agree on the time, which is probably a bug of some kind. |
| 16:01 |
Dyrcona |
s/runt/run/ |
| 16:01 |
csharp_ |
rurnt |
| 16:03 |
Dyrcona |
Bingo. |
| 16:04 |
Dyrcona |
My test vm was on UTC and db server is on EDT. Once I changed the timezone on my test vm, the tests started succeeding. |
| 16:05 |
Dyrcona |
I guess the tests are typically run on all on one vm. |
| 16:06 |
Dyrcona |
Why is time so hard? |
| 16:12 |
|
mmorgan1 joined #evergreen |
| 16:17 |
sandbergja |
Dyrcona++ |
| 08:48 |
|
mantis1 joined #evergreen |
| 08:59 |
|
dguarrac joined #evergreen |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:50 |
Dyrcona |
@decide make bug on Lp or just move the test |
| 09:50 |
pinesol |
Dyrcona: go with just move the test |
| 09:51 |
Dyrcona |
A Friday is the wrong time to ask such a question, even though I'm pretty sure the answer will be "Yes." |
| 10:06 |
Dyrcona |
Think I'll open a Lp bug and let it sit for a few days, then take care of it if no one says or does anything. |
| 10:17 |
mantis1 |
trying to navigate the log process whenever an error happens when running the marc stream importer |
| 11:08 |
Dyrcona |
If I want to limit a json_query, I can just stick the limit on the end, right? I suppose I could check the find document... Nah, I'll just try it. |
| 11:11 |
|
redavis joined #evergreen |
| 11:16 |
Dyrcona |
Trouble is. I now have to wonder if my JSON query is correct. |
| 11:22 |
Dyrcona |
Helps to know which library actually did something... :) I was using org_units that had no data on my test system for today. |
| 11:22 |
Dyrcona |
My query works. I just need to refine it a little. |
| 11:25 |
Dyrcona |
I think I just want to hammer any state that isn't complete, invalid, or error. I might skip pending at first, too.Trouble will be knowing which org_unit to test soon enough to actually cause a race condition. |
| 11:27 |
mantis1 |
csharp: do you have any examples? I never had to put in original logs before |
| 11:27 |
Dyrcona |
I suppose I have time to pregame the 12:30 run and get the information ahead of time. |
| 11:28 |
Dyrcona |
mantis1: The marc_stream_importer has a --verbose command line option that actually does something. Maybe that will help? |
| 13:52 |
pinesol |
csharp_: go with my postgresql |
| 13:52 |
csharp_ |
tu postgres es mi postgres |
| 14:37 |
Dyrcona |
mi postgres es su postgres |
| 14:38 |
Dyrcona |
Looks like I'll have to wait until Tuesday to test my hypothesis with my race condition program. I'm not getting enough events today for a/t to run very long. |
| 14:40 |
Dyrcona |
oh. my. Looks like I need to refresh my data from production. With my current out of date data, I'll have even fewer transactions next Tuesday.... |
| 14:40 |
Dyrcona |
Think I'll go ahead and grab a recent dump. |
| 15:05 |
Dyrcona |
I think I'll modify my hack to trap the errors and through them. After looking at Event.pm it appears that throwing a string would be more appropriate. |
| 12:18 |
Dyrcona |
It's not the first, and I'm sure it won't be the last, typo in a commit message. |
| 12:19 |
Dyrcona |
As long as we don't add an "orc" class, I think we're OK. :) |
| 12:19 |
|
collum joined #evergreen |
| 12:28 |
Dyrcona |
hm.. looks like that test should go in live_t/ and not t/. It fails unless services are running. |
| 12:29 |
Dyrcona |
I should have double checked that. I guess I had services running when I thought I didn't. |
| 12:33 |
Dyrcona |
So this is unlrelated to the above, but it's a new one for an autorenewal failure. We had one that apparently failed to retrieve the circulation, and it got set to complete. |
| 12:55 |
Dyrcona |
Also open-ils.trigger appears be logging messages with UTC timestamps... |
| 14:47 |
Dyrcona |
I suppose it is too late to set an invalid state, but maybe I could give it an error state.... That's better than sending the patron a bogus notification. |
| 14:49 |
Dyrcona |
Looking at this, I'm a little mystified how the error stat gets set if the AutorenewNotify fails, since the reactor always returns 1. The caller must be checking for an error object somewhere. |
| 14:56 |
Dyrcona |
Looks like I can probably add a line to check the textcode and throw the event. That should set an error state. |
| 14:58 |
Dyrcona |
This would be difficult to test.... |
| 15:00 |
berick |
grr, Zoom |
| 15:00 |
berick |
for anyone on the Rust session, cannot install Zoom at the moment. dependency funkiness |
| 15:00 |
berick |
i'll be on in a sec |
| 15:48 |
redavis |
very open to other options |
| 15:49 |
csharp_ |
we looked into https://jitsi.org/ some years back |
| 15:52 |
Dyrcona |
Well, my change to AutoRenew.pm hasn't broken anything. I don't know if it actually works. I'll have to figure out how to exercise it tomorrow. |
| 15:56 |
Dyrcona |
Guess, I'll find some circulations on my test system that would renew tomorrow, and then set something up to checkin a bunch of them while I also run the Autorenew process. That's about the best that I can do. I wonder if I could peek on the process to see where it's at and force a checkin at the right moment? |
| 15:58 |
|
mmorgan left #evergreen |
| 15:59 |
|
jihpringle joined #evergreen |
| 16:00 |
eeevil |
Dyrcona: re make a reactor fail, just die(), the caller will catch it |
| 16:13 |
JBoyer |
That relies on the browser's access to your camera and mic, and I bet Google has that working on whatever you're running, even if Zoom can't figure it out. |
| 16:13 |
eeevil |
I have to use the full-on client (linux, here. may be different on winders or mac?) |
| 16:14 |
JBoyer |
I thought it did work in Linux (same here) so maybe it has just been a long time since I've had to use it. :/ |
| 16:15 |
csharp_ |
JBoyer++ # just tested the in browser link (meekly placed below the other options) and it appears to work ok |
| 16:15 |
Dyrcona |
I haven't tried zoom in the browser on Linux, and when I click a zoom link, it opens the full-on client. |
| 16:15 |
csharp_ |
I'll try that next time |
| 16:15 |
Dyrcona |
I'll give it a try, too. |
| 13:07 |
Dyrcona |
Not that we're doing that. We decided custom notice language for all of our members would be too much to deal with. |
| 13:10 |
Dyrcona |
Reusing an existing setting is also a good idea. Maybe better. |
| 13:17 |
|
redavis joined #evergreen |
| 13:34 |
Dyrcona |
Trying to get Fieldmapper to query for the existence of a field on an object, and it's not working. I'm obviously doing something wrong. I guess I don't really need it for this test, since I can use a try block and bail if throws an error. |
| 13:36 |
Dyrcona |
oh great. ejabberd and redis are running and opensrf thinks it should use redis.... |
| 13:37 |
|
spagnod joined #evergreen |
| 13:37 |
Dyrcona |
Setting up a test vm is more complicated than it used to be, particularly when it is one that hasn't been used for several months. |
| 13:38 |
redavis |
Dyrcona++ |
| 13:38 |
Dyrcona |
Yes, I know... "Docker." But docker isn't as flexible generally speaking. |
| 13:39 |
Dyrcona |
'Cause I'm not testing a branch per se. I want to test my test script, and I'm going to use a patch for before an after. |
| 13:40 |
redavis |
I've been hearing some grumblies about docker recently. mostly about that flexibility factor. and it not keeping pace. |
| 13:42 |
|
jihpringle joined #evergreen |
| 13:46 |
Dyrcona |
And it is set up for Ejabberd in opensrf_core.xml but it complains about redis.... |
| 14:42 |
|
fguel joined #evergreen |
| 14:46 |
fguel |
Hi all, I am trying to custom my 3.12 EG server, changing the green color to our institutional color, I already modify the /openils/var/templates/opac/parts/css/colors.tt2 file but doesnt show the changes |
| 14:52 |
Dyrcona |
fguel: I'm not sure. You did install the changes, right? |
| 14:52 |
Dyrcona |
Also, back to my test: it fails on concerto because there are no renewals to look at. |
| 14:52 |
Dyrcona |
So, guess I need a new test. |
| 14:53 |
fguel |
Dyrcona yes |
| 15:01 |
Dyrcona |
You probably need to change the bootstrap template css as well. |
| 15:03 |
Dyrcona |
fguel: look under Open-ILS/src/templates-bootstrap/ |
| 15:25 |
Dyrcona |
OK. So, now I have a test script with two tests, including an eval to check the datatype of the new field in case someone (me) backports this branch prior to 3.15.... |
| 15:27 |
fguel |
Dyrcona, thanks, I modified the file /openils/var/templates-bootstrap/opac/css/style.css.tt2 and it works |
| 15:29 |
Dyrcona |
fguel: The bootstrap-templates are for the newer OPAC, you should look at those first. The older one only kicks in if someone visits a page that doesn't exist in the bootrap-templates, or if you deliberately switch them in your Apache configuration. |
| 15:37 |
fguel |
ok ok, thanks |
| 15:49 |
Dyrcona |
All right, all right. Four tests now with two that are skippable if Fieldmapper doesn't support them. |
| 15:53 |
Dyrcona |
What's one more test between friends? |
| 16:37 |
|
jvwoolf1 joined #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:12 |
|
jvwoolf1 left #evergreen |
| 14:35 |
redavis |
Congratulations!!!! |
| 14:36 |
redavis |
Also, I can believe that time has been obliterated for you. I'm holding on by a very, very thin thread. Two more meetings, and then I'm napping...HARD. |
| 14:37 |
shulabramble |
I'm gonna go home today and flop. i had to go to a scholarship interview with the Spawn yesterday which they only realized was in person 45 minutes before the meeting. |
| 14:37 |
redavis |
lol, typical spawn behavior |
| 14:39 |
redavis |
my partner was talking about his spawn telling him the morning of the SAT that he needed a ride to the test. It was the first his designated adult had heard about it. |
| 14:39 |
shulabramble |
lol, yeah, they turned off all higher thought processes between the end of their freshman year and going to Korea to teach ESL and do cultural exchange. |
| 14:40 |
redavis |
lol, but also...going to Korea to teach ESL is cool. |
| 14:40 |
shulabramble |
my first alert was hearing a scream of obscenities from their bedroom and "do you know where this road is?" |
| 15:04 |
smayo |
#info smayo = Steven Mayo, PINES |
| 15:04 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CW MARS |
| 15:04 |
terranm |
#info terranm = Terran McCanna, PINES |
| 15:05 |
shulabramble |
#topic Action Items from Last Meeting |
| 15:05 |
|
dbriem joined #evergreen |
| 15:05 |
shulabramble |
#topic bmagic will look into transferring POeditor account ownership to a generic EG account |
| 15:07 |
shulabramble |
this might be a really short meeting since everyone's doing conference stuff. since bmagic didn't do an intro, we'll kick this to next month unless anyone has any news |
| 15:07 |
shulabramble |
#action Bmagic will look into transferring POeditor account ownership to a generic EG account |
| 15:07 |
|
smayo joined #evergreen |
| 15:08 |
shulabramble |
#topic sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:08 |
sleary |
I will regroup with sandbergja in the next few days and probably toss this out for wider participation! |
| 15:08 |
shulabramble |
sleary++ |
| 15:09 |
shulabramble |
#action sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:09 |
shulabramble |
#topic Updates |
| 15:09 |
shulabramble |
There's nothing on the agenda, so the floor is open. |
| 15:09 |
redavis |
I have an update for releases. |
| 15:09 |
shulabramble |
redavis++ |
| 15:10 |
redavis |
Three point releases are due out next week on Wednesday, May 21. They are 3.13.11, 3.14.6, and 3.15.1. There aren't a ton of commits to any of them, but there are several that are high priority so this is an important maintenance release cycle. Volunteers are needed for the release team. Please fill out the buildmaster spreadsheet if you're able and willing. |
| 15:27 |
shulabramble |
#info sleary updated the Angular 18 upgrade branches this morning (LP2043490); eyes appreciated and input on if we should move to Angular 19 |
| 15:27 |
redavis |
eeevil++ |
| 15:27 |
shulabramble |
#info eeevil requests eyeballs on LP2091748 |
| 15:27 |
eeevil |
thanks, Gina, for attempting to test, also. (I'm blanking on your IRC nick, sorry!) |
| 15:28 |
redavis |
mantis++ |
| 15:28 |
shulabramble |
mantis++ |
| 15:28 |
shulabramble |
eeevil++ |
| 09:50 |
Dyrcona |
Hm... I'm trying to use idlist with cstoreeditor->search_action_circulation with a prcud personality, and I'm getting objects bacK: my $circulations = $e->search_action_circulation([{stop_fines=>'RENEW'},{idlist=>1,limit=>1000}]); |
| 09:51 |
* Dyrcona |
tries it with cstore. |
| 09:53 |
Dyrcona |
Huh. Not working there, either. I thought idlist worked with search_... . |
| 09:53 |
Dyrcona |
In that case, I'll change my approach to this test. |
| 10:10 |
Dyrcona |
Gonna take a while to go through 5.1 million circulations, 1000 at a time. :) |
| 10:13 |
Dyrcona |
I probably don't need to go through all of them to find out out what I wan to know. |
| 10:22 |
eeevil |
for idlist, I think you want this: $e->search_action_circulation([{stop_fines=>'RENEW'},{limit=>1000}],{idlist=>1}); |
| 13:34 |
Dyrcona |
The drones are all using about 3GB each. |
| 13:39 |
berick |
Dyrcona: does the basics https://github.com/kcls/evergreen-universe-rs/blob/main/evergreen-services/store/src/methods.rs |
| 13:42 |
Dyrcona |
I haven't updated my clone of that repo in a while. I should have a look. |
| 13:42 |
Dyrcona |
berick: I think there's a memory leak in cstore, at least with Redis. I'm testing the same thing with Ejabberd to see if the problem is more general. |
| 13:48 |
jeffdavis |
I'm getting "connection refused" when I try to visit git.evergreen-ils.org in a browser. git pull works fine |
| 13:49 |
Dyrcona |
speaking of oom-killer. jeffdavis++ |
| 13:49 |
Dyrcona |
I'm going to reboot git.evergreen-ils.org to make sure everything comes back up correctly. |
| 11:53 |
Dyrcona |
I imagine the mat view would be faster in joins, too. |
| 11:53 |
Bmagic |
I would imagine a view would be slower than a raw table, because the view is just another query, which enguages the query planner at a deeper level |
| 11:54 |
Dyrcona |
I find it interesting that grabbing only 1 row takes about the same time with either, though. |
| 11:55 |
Bmagic |
hmm, I'm not sure how retrieving a single row is much of a test |
| 11:55 |
Dyrcona |
Also, I've written queries with subqueries that are faster than those with joins on tables, and a view is a query more or less, so I guess it depends. |
| 11:55 |
Dyrcona |
Bmagic: It's not really, but I was curious about various timings. |
| 11:56 |
Dyrcona |
This goes back to something that I mentioned yesterday about a custom view we have that got really slow with Pg 16 and the slowness not being where I expected it to be. |
| 12:32 |
Dyrcona |
eeevil: Yep. |
| 12:33 |
redavis |
To be fair, nothing we perceive is actually up-to-date. |
| 12:33 |
Dyrcona |
I was considering the trigger approach but decided that asset.copy has enough triggers, rules, and fk relationships already. It doesn't need another. |
| 12:34 |
Dyrcona |
We're going with the traditional view with an improved query for Pg 16 in production. I'll see what folks here say about putting the materialized view on a dev system for testing. I'd like to have the person who uses it test both with their usual workflows. |
| 12:35 |
eeevil |
redavis: tell that to circ managers running reports! ;) |
| 12:35 |
redavis |
eeevil, do they really want to hear about the mythology of "instant" though? |
| 12:36 |
eeevil |
whether they want to or not... |
| 12:41 |
Dyrcona |
If we can refresh the mat view once every hour, 1/2 hour, 15minutes, whatever, and it takes seconds, is that good enough? In my estimation, probably yes, and I don't slow down copy updates that happen far more frequently. |
| 12:41 |
Dyrcona |
And I'll grant you that performance in Pg 8.3 was nothing like it is in Pg 16. |
| 12:43 |
Dyrcona |
In reality it will probably add less than 100ms to a copy update, maybe if the trigger is deferred and after and something else, it won't really add anything at all. I dunno if I can have a trigger not block a transaction from committing. I'll have to look. |
| 12:44 |
Dyrcona |
Anyway, that was where my train of thought was heading with the decision to test out a materialized view. |
| 12:45 |
Dyrcona |
I find it interesting that the mat view without the index is slower for individual record retrieval than the traditional view in my non-scientific test. It does seem faster to use overall, though. |
| 12:48 |
Dyrcona |
There's some viewdoo going on... *coughs* |
| 12:54 |
redavis |
Dyrcona, I think it's cool that you're messing with optimizations. |
| 12:56 |
Dyrcona |
redavis: Thank you. This is a CWMARS view that was implemented before I got here. It was never really fast because 1.5 to 1.75 million rows are not fast in a view. When we upgraded to Pg 16, it got really slow, so I had a look with explain and started changing it. The performance of the traditional view is back to where it was pre Pg 16. I want to see if the materialized view is even better. |
| 07:32 |
|
collum joined #evergreen |
| 08:35 |
|
redavis joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 09:09 |
csharp_ |
spagnod: we just have the one image that's fully rebuilt every time (which is useful for testing Git branches, etc.) - if you're looking for something more permanent, you might try installing on a VM? |
| 09:10 |
csharp_ |
or on a container with persistent storage? (I haven't done a lot of container work, so just throwing spaghetti at the wall) |
| 09:23 |
|
Dyrcona joined #evergreen |
| 09:29 |
spagnod |
Alright, I'll try a VM |
| 09:53 |
Dyrcona |
Testing a custom db upgrade and got this: psql:cwmars-3.7.4-3.15.0-upgrade-db.sql:16687: ERROR: cannot CREATE INDEX "usr_setting" because it has pending trigger events. |
| 09:54 |
Dyrcona |
Something like that usually ends up with a ROLLBACK, but in this case there's no ROLLBACK in my output. |
| 09:55 |
Dyrcona |
I wonder if \set ON_ERROR_STOP on prevented the rollback from happening. I find the documentation for that setting to be confusing. "You keep using that [setting]. I don't think it means what you think it means." |
| 09:56 |
Dyrcona |
Think I'll try it again without that set. |
| 10:18 |
Dyrcona |
open-ils.trigger.event_group.fire |
| 10:19 |
Dyrcona |
maybe, I'll let run-pending deal with it? |
| 10:26 |
Bmagic |
time will tell :) |
| 10:27 |
Dyrcona |
It "works" on my test system. |
| 10:28 |
Dyrcona |
FYI, this is a modification to a program to find missed courtesy/autorenew events and recreate them. We're still getting a few for circulations with weird due dates, like 2:00 am.... |
| 10:29 |
Dyrcona |
What it's going to do now is to create the autorenew event and let the next --run-pending for that granularity pick it up. |
| 10:30 |
Dyrcona |
Since we have a batch kicking off right about now, I'll wait until about 45 minutes to try it on production. |
| 10:31 |
Dyrcona |
Looks like it's only 1 or 2 per day. |
| 10:32 |
Dyrcona |
On my test system where this has been running for a week, I don't have any since the new schedule started. |
| 10:32 |
Dyrcona |
Production has 2 that should have been picked up yesterday when this started, but it could be because of the weird due dates in the circulation. |
| 10:34 |
Dyrcona |
I wonder how run pending is going to cope with the constant flood of events being created on my other test vm? |
| 10:40 |
Dyrcona |
Looks like it's only working on those that were pending when I started it, which is what I expected. |
| 10:58 |
|
sandbergja joined #evergreen |
| 11:09 |
|
Christineb joined #evergreen |
| 14:01 |
* Dyrcona |
gives it a shot. |
| 14:01 |
Bmagic |
I think build (because otherwise, why do we build?) |
| 14:01 |
Dyrcona |
bmagic: it might depend on if you do build-prod or just build. |
| 14:02 |
Dyrcona |
I'm trying it on a test system. We'll see what happens. |
| 14:03 |
Dyrcona |
For my situation just copying the file worked. |
| 14:03 |
Dyrcona |
After a Clear Cache and Hard Reload. |
| 14:06 |
Dyrcona |
Bmagic: I added the branch for Lp 2018534 to a 3.7.4 branch because that affects us in production. |
| 09:51 |
Dyrcona |
Perhaps I'll experiment with Rust again in the coming weeks. |
| 09:52 |
berick |
that reminds me I keep meaning to send a "any interest in rust working group" email to the dev list |
| 09:53 |
mantis |
kicking off our pingest; we'll see how long it takes :-X |
| 09:57 |
Dyrcona |
mantis: You can experiment with the --batch option sizes. In my test enviroment, I find going with 1000 runs pretty fast. |
| 09:57 |
mantis |
I have a batch of 10000 for now |
| 09:57 |
Bmagic |
mantis: if you use the linux command "time" you can let the computer tell you how long it takes. You would execute pingest.pl like you would normally, but put the word "time" in front. Like "time pingest.pl --switches....." |
| 10:07 |
mantis |
do you use a particular "max-child" flag? |
| 10:11 |
JBoyer |
If memory serves that's how many active simultaneous processes will be running, so the best value depends on your hardware. On a test system you could use the number of processors in the system to go as fast as possible, but should use a lower count for prod, depending on the use it sees. |
| 10:11 |
Dyrcona |
No, I usually go with 8, but it depends on how many cores your db server and/or utility machine have, assuming that they're separate. |
| 10:11 |
JBoyer |
(meaning the number of cpus on your database, not necessarily the machine running it.) |
| 10:15 |
Dyrcona |
Also, if you don't skip the browse ingest, there will be 1 child process doing the browse ingest on all of the records because the browse ingest can't be done in parallel. You eventually run into a deadlock(?) when two processes try to update the same record. (Mark Twain seems to be a common one for us.) |
| 10:45 |
Bmagic |
that's right |
| 10:45 |
|
Llewellyn joined #evergreen |
| 10:47 |
Dyrcona |
Do we actually send it plain text though? I thought it get MD5'd before it got to the server? I guess that's only after it arrives, huh. |
| 10:47 |
Llewellyn |
I did a test on it yesterday, I added a logger statement to Actor.pm and was able to capture incoming passwords. |
| 10:47 |
berick |
it's plain text via the API, salted+hashed in the db |
| 10:47 |
Bmagic |
I'll let Llewellyn take that one |
| 10:47 |
Dyrcona |
Llewellyn++ |
| 10:59 |
Dyrcona |
If you got a MITM, you got bigger problems. |
| 10:59 |
Bmagic |
Llewellyn: correct, but* the man in the middle can just use the MD5 version of the password (just like the client software did) and they'd login no problem |
| 10:59 |
Llewellyn |
hmmm |
| 10:59 |
sleary |
^^ SSO branch with a PR ready for people to test. |
| 10:59 |
Bmagic |
sleary++ |
| 11:01 |
Bmagic |
Llewellyn: in other words: the benefit is nill, with the exception being: if the patron uses the same password in other places, the attacker would be able to access their account in the other places now that they had the raw password. Whereas, the md5 version wouldn't work in other places |
| 11:01 |
Llewellyn |
better than nothing imo |
| 12:07 |
dguarrac |
Dyrcona: Would a STAFF_CHR penalty applied just at that org unit work? |
| 12:07 |
dguarrac |
I don't actually know how the H in the CHR works. |
| 12:08 |
Dyrcona |
dguarrac: Yeah, that probably will work. |
| 12:08 |
Dyrcona |
I can test it. |
| 12:08 |
* Dyrcona |
overlooks penalties sometimes. |
| 12:09 |
Dyrcona |
dguarrac++ That works. |
| 12:09 |
dguarrac |
woohoo! |
| 13:05 |
terranm |
If any seasoned developers are available for new devs today at 3pm eastern, I'd love some guidance on this bug - https://bugs.launchpad.net/evergreen/+bug/2107209 |
| 13:05 |
pinesol |
Launchpad bug 2107209 in Evergreen "Author links break in several places when MARC 100 subfields are present" [High,New] |
| 13:59 |
|
terranm joined #evergreen |
| 14:21 |
pinesol |
News from commits: LP2106780 Adjust karma.conf.js for concurrency, logging, timeouts <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fd5bdc1da02a345394a31c0946ed7336671d1b40> |
| 14:21 |
pinesol |
News from commits: LP2106780 IDL service, Item attr unit test fixes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b39e987eded3dce5921059d2c910fcdb1930d480> |
| 14:21 |
pinesol |
News from commits: LP2106780 Unit test updates for 3.15 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=be56cbc0adc5e6ed799d0eecbafc0906fd23ab8a> |
| 14:54 |
|
collum joined #evergreen |
| 14:58 |
terranm |
NVM I just figured it out, and it requires the change of a single character, lol |
| 15:02 |
csharp_ |
terranm++ |
| 11:32 |
ianskelskey |
What do you mean? |
| 11:41 |
csharp_ |
ianskelskey: not sure what import method you're doing but there are match sets and merge profiles within vandelay that the UI import and some scripty tools use |
| 11:41 |
csharp_ |
may not be relevant in your case - just theorizing |
| 11:44 |
ianskelskey |
I'm just gathering any information I can before I start looking at code/custom solutions so I appreciate it. I'll run it by our cataloger and see what she says. |
| 11:51 |
ianskelskey |
It looks like the match set is Hoopla and the merge profile is full overlay if that means anything |
| 11:54 |
ianskelskey |
We've been running a test with 100 records and its been running for over 2 hours so far with about 65 complete. |
| 11:56 |
jihpringle |
ianskelskey: it might be worth looking at what your Hoopla match set is matching on compared to other match sets you have |
| 11:58 |
collum |
ianskelskey: ^ In the MARC Batch Import/Export screen there's a tab for Record Match Sets. You can find how Hoopla is defined through that interface. |
| 11:59 |
ianskelskey |
Is there something in particular I should look for there. I was in that screen recently poking around. |
| 11:48 |
sleary |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sleary/LP2106666-color-mode-with-windows7-support-rebase |
| 11:48 |
Bmagic |
holy smokes that was fast |
| 11:49 |
sleary |
I know these stylesheets too well :( |
| 12:10 |
phasefx |
Bmagic: abneiman: I wrote something simpler and more targeted than pg_diff, and nothing is actually missing. Counts for rows in each table are off by 1 with the test data; going to double-check that |
| 12:13 |
Bmagic |
sleary: maybe I should've just pushed to the real branches rather than making signoff branches |
| 12:17 |
Bmagic |
ok, it's on main now |
| 12:17 |
sleary |
Bmagic++ |
| 12:17 |
sleary |
thanks for testing that |
| 12:20 |
Bmagic |
no problem, I'm doing 3.14 and 3.15 too, and I'll post on LP in a minute |
| 12:22 |
abneiman |
Bmagic++ sleary++ |
| 12:28 |
Dyrcona |
Windows 7, really? |
| 12:38 |
|
jihpringle joined #evergreen |
| 12:40 |
|
smayo joined #evergreen |
| 12:42 |
jeffdavis |
sleary++ |
| 12:45 |
phasefx |
Bmagic: abneiman: and my off-by-1 rows came from the database snapshot capturing some of my testing. I think we're good! |
| 12:45 |
abneiman |
@phasefx++ |
| 12:45 |
pinesol |
abneiman: git diff origin/hamster |
| 12:46 |
abneiman |
phasefx++ |
| 12:47 |
phasefx |
abneiman: Bmagic: I celebrated too soon. email.login.issuer and email.login.digits exist in an upgraded db but not a pristine one |
| 12:47 |
* abneiman |
has no such restraint |
| 12:47 |
abneiman |
phasefx: s'ok there's still time to work stuff out |
| 12:48 |
phasefx |
I'm going to redo the snapshot, make sure I rule out changes introduced from testing |
| 12:48 |
Bmagic |
what you're doing is pretty close to the logic that make_concerto_from_evergreen_db.pl does |
| 12:48 |
phasefx |
but there are definitely things off |
| 12:49 |
phasefx |
circ.void_overdue_on_longoverdue in a pristine db, but not in an upgraded one |
| 12:49 |
Bmagic |
do you run this type of test for each release? And this one is giving different results from previous releases? |
| 12:51 |
phasefx |
who me? no, I haven't been doing this previously, though I played with the idea a long time ago |
| 13:02 |
|
Dyrcona joined #evergreen |
| 13:05 |
csharp_ |
@dunno add user opensr does not exist |
| 14:01 |
pinesol |
Rogan knows too much about action triggers. |
| 14:39 |
abneiman |
probably true, tbh |
| 14:46 |
Dyrcona |
:) |
| 14:47 |
Dyrcona |
I know more about it than I did yesterday, mostly by trying things on a test system and seeing what happens. |
| 15:37 |
Dyrcona |
I picked the wrong day to test of a change in a script... |
| 15:37 |
Dyrcona |
19,756 events and rising. |
| 17:11 |
|
jvwoolf1 joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 12:34 |
mantis |
Bmagic++ |
| 12:35 |
Bmagic |
let us know if you have any questions! |
| 12:37 |
|
jvwoolf joined #evergreen |
| 12:38 |
mantis |
Bmagic: definitely for sure |
| 12:39 |
mantis |
I would like to start these on test servers during off hours next week; do you have any best practice tips? We haven't been able to perform a successful parallel ingest before |
| 12:39 |
mantis |
I think we did try but there was issue with either storage or just having too many records and a timeout happens |
| 12:39 |
mantis |
not 100% sure on that but it definitely had something to do with the size of our collection |
| 12:40 |
Bmagic |
what's the total number of bibs? |
| 12:44 |
mantis |
we're somewhere in the 600k area - at least that's what I'm seeing when running counts on IDs |
| 12:45 |
Bmagic |
the main issue we've run into is running the reingest at the same time as a backup. That usually results in a full disk situation. So if your backups are running at night, you want your reingest to finish (or a portion thereof) before the backup starts |
| 12:49 |
mantis |
Bmagic++ |
| 12:49 |
Dyrcona |
mantis: I run it on 1.8 million bibs all the time. |
| 12:49 |
mantis |
Dyrcona: how often? |
| 12:50 |
Dyrcona |
At least monthly on my test systems. |
| 12:50 |
Dyrcona |
it is generally only necessary after database upgrades. |
| 12:51 |
Dyrcona |
Well, upgrades that affect search. |
| 12:52 |
mantis |
what's the difference between parallel and queued? parallel does it in concurrent batches? |
| 13:04 |
Dyrcona |
The purpose of ingest is to make sure that the search indexes are up to date with your records. This should be taken care of normally, but under some circumstances, they get out of whack. |
| 13:04 |
mantis |
why do you run ingests monthly? |
| 13:05 |
Dyrcona |
I copy a dump of production data to a local server. I load that dump into a database. I make a copy of that database which is updated to a more recent version of Evergreen. That gets dumped again, and reloaded as yet a third database. |
| 13:06 |
Dyrcona |
This third database is connected to a test vm running that release of Evergreen. I run a pingest on that database to make sure that search works. |
| 13:07 |
Dyrcona |
I find it is often more convenient to just do a pingest of the whole thing rather than do the SQL bits included in the DB upgrades' comments. |
| 13:08 |
Dyrcona |
In production, we pretty much never do an ingest, unless we added a new search index (rare) or just did a version upgrade (probably less rare). |
| 13:08 |
mantis |
ah I see |
| 13:08 |
mantis |
so it's just a preference |
| 13:09 |
Dyrcona |
it might fix your KPAC issues depending on the problem. I don't know enough about the particulars to really say. |
| 13:09 |
Bmagic |
mantis: he's reingesting on a test machine. Which can be done willy nilly without concern about uptime and production nightly backup interference. |
| 13:10 |
Bmagic |
It's a good idea to get familiar with the procedure on a test machine though! |
| 13:10 |
Bmagic |
You can use the expierence that you gain from running the procedure on a test machine to see how long it takes, which should translate roughly to the time it will take on production (if your test machine is close in size and shape) |
| 13:10 |
Dyrcona |
If the Evergreen upgrade affects search indexes, then doing some sort of ingest is pretty much mandatory, or search will not reflect the changes in the upgrade. That's why I do the ingest on the database that has been upgraded to a more recent version of Evergreen than the original data. |
| 13:12 |
Dyrcona |
Not knowing the history of your database and upgrades, I can't say if an ingest will solve your KPAC search issues or not. |
| 13:13 |
mantis |
I can always give it a try anyway! |
| 13:13 |
mantis |
thanks to you both |
| 13:13 |
Bmagic |
one way to know: copy your production database to a test machine, ensure that you're having the same issue on your test machine as you do on production. Then run your reingest on the test machine, and see if it makes a difference |
| 13:14 |
|
redavis joined #evergreen |
| 13:17 |
Dyrcona |
You should be able to do either type of ingest while users are using Evergreen. They won't notice for the most part. |
| 13:17 |
Dyrcona |
We used to kick a pingest off after the upgrade and start services so users could use Evergreen while the ingest was chugging away. |
| 10:21 |
abneiman |
(that's what MY brain feels like, anyway) |
| 10:22 |
abneiman |
just wanna nap in a tree all day and eat some plants |
| 10:22 |
redavis |
coked-up-squirrels and barbiturate-sloths are siblings. possibly twins. possibly identical twins. |
| 10:23 |
Dyrcona |
Anyway, I think I've had success in splitting up our daily courtesy/autorenewal process. I was able to test the filters Monday and they work! |
| 10:23 |
redavis |
Dyrcona++ |
| 10:24 |
Dyrcona |
redavis: I think the JEDI is just a JSON representation of the EDI. |
| 10:24 |
Dyrcona |
Same data in a different format. |
| 10:26 |
Dyrcona |
The JEDI was (is?) used internally by Evergreen and not sent to vendors. |
| 10:26 |
Dyrcona |
I don't remember if the new EDI process uses it or not. |
| 10:27 |
redavis |
++ |
| 10:27 |
Dyrcona |
Ha! We're supposed to do this Phishing security training/test for insurance purposes, and the invitation email ended up in my spam. Yay, Google! |
| 10:27 |
redavis |
berick, do you know? |
| 10:28 |
Dyrcona |
berick should know for sure. |
| 10:29 |
berick |
yeah JEDI is the internal representation of the EDI. it's mainly just a snapshot for debugging |
| 12:34 |
|
jihpringle joined #evergreen |
| 13:09 |
phasefx |
--load-concerto-enhanced in main (and 3.15-rc) gave me a duplicate key error on permission.grp_tree |
| 13:10 |
Bmagic |
ah! I got that too, the other day, probably needs regenerated now |
| 13:12 |
Bmagic |
for feedback fest, I got enhanced concerto loaded on the test machine, but encountered that issue and figured it was due to all of the patches I'd loaded onto the source code. But now that they've been merged, it's time to regenerate the enhanced concerto to bring it up to current |
| 13:13 |
phasefx |
@Bmagic++ |
| 13:13 |
pinesol |
phasefx: uh huh.. please tell me more about that |
| 13:13 |
phasefx |
urg, my IRC habits are fading away |
| 13:54 |
redavis |
But it's not happening throughout the entirety of the upgraded libraries? |
| 13:56 |
jihpringle25 |
no we've only had reports from 6 libraries and for some of them some computer are affected and others are normal |
| 13:57 |
jihpringle25 |
I'm thinking something browser related (Chrome) but so far we haven't been able to pinpoint anything |
| 13:58 |
redavis |
++. is their a possibility of having them test it using Firefox? |
| 13:58 |
mmorgan |
jihpringle25: Does sound browser related. Try a different browser on an affected computer? Try disabling extensions, Incognito mode? |
| 13:58 |
redavis |
or something else? |
| 14:00 |
jihpringle25 |
at least one library tried it in Edge and it looked normal |
| 15:12 |
shulabramble |
#topic Bmagic will look into transferring POeditor account ownership to a generic EG account |
| 15:12 |
Bmagic |
I did some poking around |
| 15:13 |
Bmagic |
defer for next time |
| 15:13 |
shulabramble |
#action Bmagic will look into transferring POeditor account ownership to a generic EG account |
| 15:13 |
shulabramble |
#topic sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:13 |
sleary |
still in progress, actual progress being made, still not done |
| 15:13 |
shulabramble |
#action sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:14 |
shulabramble |
#topic abneiman will discuss moving the developer's meeting with shulabramble and poll the community |
| 15:14 |
abneiman |
we discussed this! |
| 15:14 |
abneiman |
and we will table this till later since as of now, Shula is the dev meeting leader & without av computer things |
| 15:15 |
abneiman |
so, this can be struck for now |
| 15:16 |
abneiman |
shulabramble++ |
| 15:17 |
shulabramble |
#topic Dyrcona will look at https://bugs.launchpad.net/evergreen/+bug/2073561 |
| 15:17 |
pinesol |
Launchpad bug 2073561 in Evergreen 3.14 "Incorrect content in the config.coded_value_map after applying the upgrade script from 3.12.3 to 3.13.0" [High,Fix committed] |
| 15:17 |
shulabramble |
Okay, fix committed! |
| 15:17 |
shulabramble |
Dyrcona++ |
| 15:17 |
shulabramble |
#topic Updates |
| 15:18 |
shulabramble |
#topic Evergreen |
| 15:18 |
shulabramble |
#topic Thanks to Terran et al. for a very successful Feedback Fest! FBF stats |
| 15:19 |
shulabramble |
#topic 3.15-rc built this morning (thank you Galen!) and is being tested this afternoon, with release announcement & merge un-pause expected later today |
| 15:19 |
shulabramble |
#topic No merges to 3.15 branch unless they are critical bugfixes, lint fixes, or documentation |
| 15:19 |
terranm |
Yay Feedback Festers! |
| 15:19 |
terranm |
Festers doesn't sound nice |
| 15:19 |
shulabramble |
#topic 3.15.0 is slated for release next Wednesday 16th, as is 3.14.5 and 3.13.10 |
| 15:20 |
abneiman |
terranm++ feedback-festers++ |
| 15:20 |
shulabramble |
gmcharlt++ abneiman++ |
| 15:20 |
collum |
terranm++ |
| 15:20 |
terranm |
And Bmagic++ and JBoyer++ for building test servers! |
| 15:20 |
shulabramble |
bmagic++ jboyer++ |
| 15:20 |
abneiman |
do we want to talk about point releases next week? |
| 15:20 |
redavis |
Bmagic++ JBoyer++ |
| 08:45 |
|
mmorgan joined #evergreen |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
dguarrac joined #evergreen |
| 09:36 |
Dyrcona |
My custom a/t filters with a subquery to limit by patron home_ou for autorenewals/courtesy notices seems to work. I got only the libraries expected in my first test run. |
| 09:37 |
Dyrcona |
The a/t runner only ran for about 16 minutes (15m54s according to time). |
| 09:37 |
|
collum joined #evergreen |
| 09:37 |
Dyrcona |
This looks promising for a move to production soon. |
| 09:56 |
Dyrcona |
It should probably only work when a granularity is specified.... Not sure. |
| 10:08 |
Dyrcona |
Lp 2106399 |
| 10:09 |
pinesol |
Launchpad bug 2106399 in Evergreen "Allow override of delay and max_delay from action_trigger_runner.pl command line" [Wishlist,New] https://launchpad.net/bugs/2106399 - Assigned to Jason Stephenson (jstephenson) |
| 10:10 |
Dyrcona |
Wild: I ran the same test on Pg 10, and it took 35 minutes. The 16 minutes was on Pg 17. The Pg 10 database is optimized to use about 80% of the hardware whereas Pg 17 is using default optimization. |
| 10:13 |
Dyrcona |
Same data and same results. It really makes sense to upgrade PostgreSQL just for the better performance. |
| 10:14 |
* Dyrcona |
starts the next test on Pg 10 to see how long it takes. |
| 10:55 |
|
Christineb joined #evergreen |
| 11:11 |
|
jihpringle joined #evergreen |
| 11:28 |
|
redavis joined #evergreen |
