| 14:42 |
eeevil |
you might be able to disable the cookie requirement by adding a path match on JUST the quipu url to turn off the perl variable |
| 14:43 |
eeevil |
yes, that's right. just add register as a peer to home etc |
| 14:43 |
csharp_ |
eeevil++ |
| 14:54 |
jeffdavis |
I'm finding that if I go directly to a results page with no cookie, I get redirected to nb_bounce 6-12 times before a cookie is set and my page loads - is that amount of redirecting expected? |
| 14:54 |
jeffdavis |
(testing the patch for 2113979) |
| 14:57 |
eeevil |
it's not, and we haven't seen that here ... and that doesn't actually make sense... maybe the JS is redirecting before the browser stores the cookie that came in the header? you should def be getting a set-cookie header /every/ time you hit the nb_bounce url. def interested (on the bug) in any details that might point to a cause |
| 15:00 |
JBoyer |
The Network tab of the browser console should be a big help there. Oh, jeffdavis, is that system behind multiple apache servers or just one (like a test system?) |
| 15:05 |
jeffdavis |
test system with HAProxy in front of nginx in front of Apache |
| 15:06 |
JBoyer |
I think my one / many apache server concern is no problem, I was thinking about the localhost memcached that the translator defaults to using, but that's not the cache used to store the cookie. |
| 15:07 |
JBoyer |
So I'm not sure what would cause that. Just using Chrome? |
| 15:08 |
jeffdavis |
This is in Chromium. |
| 16:13 |
csharp_ |
mmorgan: no one can hear you sing on IRC!!! |
| 16:13 |
csharp_ |
lalalalala |
| 16:14 |
mmorgan |
That is a good thing! |
| 16:14 |
berick |
eeevil: hm, i'm not too surprised the router isn't load balancing. i could have missed that. I would expect the router to fall-back to the second-registered service if the first-registered disappeared, though. pretty sure I tested that specifically. but i'm all for load balancing. happy to ta |
| 16:15 |
berick |
lk more in email/lp/whatevs. |
| 16:15 |
berick |
@band add The OpenSRF Mother Smurf |
| 16:15 |
pinesol |
berick: Band 'The OpenSRF Mother Smurf' added to list |
| 16:22 |
eeevil |
yeah, it'll do the right thing if index 0 in service instance list fails (and if next one fails, etc), but it doesn't rotate. I have code for that (and polished up osrfList with Pack and Rotate). the other thing is there's no delivery failure detection at all (that's why I was beating on the STREAM drum). I've mostly got that figured out, too. the last thing is "bus reset" ... if it's rebooting the universe on service restart, that's no good. I / |
| 16:22 |
eeevil |
think/ that's what it's doing. but, I'm still just starting to dig into that part. last is ACL restrictions -- my hope is to allow routerless mode with /at least/ public/private separation. but that's currently a stretch goal ATM. and then with that, for the "bunch of standalone full servers" crowd (no cross-reg ever), an automatic routerless mode to speed things up in that simple(r) case |
| 15:04 |
shulabramble |
since Bmagic doesn't look to be around, does anyone else have any updates on this? |
| 15:05 |
shulabramble |
in that case |
| 15:05 |
abneiman |
I imagine this task may be transferred to the nascent Infrastructure Committee, when that is officially formed |
| 15:05 |
shulabramble |
abneiman++ |
| 15:05 |
shulabramble |
#action Bmagic will look into transferring POeditor account ownership to a generic EG account/moving this task to the nascent Infrastructure Committee |
| 15:06 |
shulabramble |
#topic sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:06 |
sleary |
oof, please carry forward |
| 15:06 |
shulabramble |
#action sleary and sandbergja will report progress on test writing wiki pages next month |
| 15:06 |
shulabramble |
#topic Release Manager needed for next major release |
| 15:07 |
shulabramble |
Though I think that also falls under New Business at the end with the assembly of a team for 4.0/Fall Release |
| 15:07 |
redavis |
yes |
| 15:08 |
shulabramble |
Alrighty then, we'll address all that together at the end. |
| 15:08 |
shulabramble |
#topic Updates |
| 15:25 |
sleary |
redavis I do not recall what role I had last time |
| 15:25 |
sleary |
I was not The Builder |
| 15:25 |
redavis |
There's WAY more time spent from committers and testers...and Terran wrangling BSW and FF...and yeah. |
| 15:26 |
mdriscoll |
Testing tarballs took me about 10 hours from Jan - April |
| 15:26 |
abneiman |
yeah, and relteam members who are also core committers are probably going to spend more time on reviews / commits than on team activities |
| 15:26 |
redavis |
mdriscoll++ |
| 15:27 |
shulabramble |
mdriscoll++ |
| 15:30 |
redavis |
Also, just a note that those time estimates are for a feature release. They're a little shorter for maintenance releases (so please volunteer for this month). |
| 15:30 |
shulabramble |
redavis++ |
| 15:30 |
redavis |
(a LOT shorter? how do I sell this quickly?) |
| 15:31 |
mdriscoll |
I'll test tarballs again. |
| 15:32 |
redavis |
mdriscoll++ |
| 15:32 |
shulabramble |
People who volunteer for maintenance releases receive the blessings of Githulhu for at least a week. |
| 15:32 |
redavis |
Oh, up until the next maintenance release cycle. |
| 15:33 |
shulabramble |
What those blessings entail are unknown, but you'll have them. |
| 15:33 |
phasefx |
you can count me in for testing too, and emergency commit bit |
| 15:33 |
shulabramble |
mdriscoll++ phasefx++ |
| 15:33 |
redavis |
only Githulhu knows. |
| 15:33 |
* phasefx |
needs to remember that he volunteered... |
| 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 |
