Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148
| 14:45 | Dyrcona | osrf_control --diagnostic says we're OK. |
| 14:46 | csharp_ | grep FATAL postgresql.log |
| 14:48 | Dyrcona | Nothing since 6:22 am this morning and it wasn't something that I did. |
| 14:50 | Dyrcona | I have 2 test instances talking to different dbs on the same db server. Maybe I need to up the connection count? Anyway, I've restarted services on the one that I'm trying to test. |
| 14:51 | Dyrcona | There we go... |
| 14:52 | Dyrcona | Nope, the problem is not the lambda syntax. Nothing changed in the output. |
| 14:52 | Dyrcona | Well, I'll empty cache and hard reload to make sure. |
| 11:58 | Christineb joined #evergreen | |
| 12:34 | collum joined #evergreen | |
| 13:26 | Rogan joined #evergreen | |
| 14:46 | Dyrcona | Huh. Our 3.15.4 production server doesn't sort the part drop down while a 3.15.4 test branch appears to sort it by label (close, but incorrect), and there's no differences in Open-ILS/src/eg2/src/app/staff/cat/volcopy/volcopy.service.ts between the branches. Maybe it's in the html file? |
| 14:46 | mmorgan left #evergreen | |
| 14:49 | Dyrcona | No differences in the files in the cat/volcopy/ directory between the two branches.... |
| 14:50 | Dyrcona | going all the way back up to Open-ILS/src/eg2/ I can't find any differences. |
| 15:26 | Dyrcona | The build configuration should not have an effect on whether or not it sorts, should it? In one case, I'm doing `ng build` in production looks like it is `ng build --configuration=production`. |
| 15:36 | Bmagic | Dyrcona: weird. No, I don't think the resulting drop down menu would change order depending on the presence of --configuration=production or not |
| 15:37 | Bmagic | Same cherry-picks on both environments? |
| 15:38 | Dyrcona | Bmagic: I didn't look hard enough. If you scroll down far enough the drop down on the test vm isn't sorted any more. Guess the data is clustered better on the test database. |
| 15:42 | Bmagic | I have an unrelated question to the room: if an item is Lost and the due date is updated to be in the future, will Evergreen adjust all related Lost billing to zero? |
| 16:03 | Dyrcona | Bmagic: I don't think so if the bill has been generated. |
| 16:12 | Bmagic | ty |
| 11:32 | jihpringle joined #evergreen | |
| 11:35 | Bmagic | I thinkI found it: " Y " |
| 11:41 | csharp_ | following up on bug 2137020 (thank you gmcharlt)... |
| 11:41 | pinesol | Launchpad bug 2137020 in Evergreen "In-query PCRUD permission testing can fail of classname is an SQL reserved word" [High,Fix committed] https://launchpad.net/bugs/2137020 |
| 11:42 | csharp_ | looks like we need more quoting to accommodate UPDATE and DELETE SQL |
| 11:42 | csharp_ | either that or change the class name from "asc" to something non-sql-reserved? |
| 11:43 | csharp_ | (the latter might be easier, but it's probably Bad™ to allow the reserved-word-in-sql landmine to remain |
| 15:58 | eby joined #evergreen | |
| 15:58 | briank joined #evergreen | |
| 16:37 | jihpringle joined #evergreen | |
| 16:47 | gmcharlt | csharp_++ |
| 16:48 | gmcharlt | csharp_: I've tested and pushed your patch |
| 16:55 | Dyrcona | csharp_++ gmcharlt++ |
| 17:04 | mmorgan left #evergreen | |
| 17:05 | jihpringle joined #evergreen |
| 13:26 | Dyrcona | Though the console says websocket connection failed. |
| 13:27 | Dyrcona | Maybe I messed up the option to set the websockets port. We need to make it stop and scream loudly if you pass an invalid option to configure. |
| 13:30 | Dyrcona | How come I can't find it with `grep -r _PORT /openils/var/web/js`? |
| 13:33 | Dyrcona | Looking in config.log alot of the autoconf features tests are failing. |
| 13:37 | csharp_ | Dyrcona: grep -r _PORT /openils/lib/javascript/ |
| 13:37 | Dyrcona | csharp_++ I set the port correctly. |
| 13:39 | Dyrcona | Well, everything ws running, but I just restarted websocketd, nginx, and apache, and it's working, now. |
| 14:04 | Dyrcona | Easy enough to fix. |
| 14:05 | * Dyrcona | may start using merge in my custom branches to avoid force pushing and filling the remote repository with dangling objects. |
| 14:15 | sandbergja joined #evergreen | |
| 14:18 | Dyrcona | csharp_: Our Quipu customization for display seems to be working. They don't have a test system set up for me to try the other changes, but I suspect that they'll still work. |
| 14:23 | Dyrcona | Hm... ChiliFresh isn't working. I thought I backported the code... |
| 14:24 | csharp_ | Dyrcona: yeah, we're asking for some sort of test |
| 14:25 | Dyrcona | We intend to ask Quipu for a test also. |
| 14:25 | Dyrcona | I think my issue is memcached now... |
| 14:25 | Dyrcona | It likely has the 404/no images cached or something like that. |
| 14:26 | Dyrcona | Yeahp. Records that I haven't viewed yet are getting covers. |
| 09:07 | mmorgan joined #evergreen | |
| 09:41 | Dyrcona | Oh, great. Ubuntu is basically moving more to the App Store model with 26.04: https://discourse.ubuntu.com/t/ubuntu-26-04-lts-the-roadmap/72740 |
| 09:42 | Dyrcona | May be that it's time to switch to ARCH on the work laptop, too. |
| 09:43 | Dyrcona | I don't know how much this will affect server installation. I downloaded the snapshot image today, but thought that I might wait for the beta release before actually testing. Maybe I should jump the gun on this one and start earlier? |
| 09:44 | Dyrcona | Also, "Resolute Raccoon..." They really missed an opportunity by not naming it "Rocky Raccoon," but maybe Apple Records would have sued them..... |
| 09:55 | Dyrcona | I guess "rocky" is bad for other reasons. |
| 09:55 | Dyrcona | Question: Does anyone out there allow Communico to have API access for their app? |
| 12:32 | Dyrcona | Creating a hold note doesn't seem to work. |
| 12:34 | Dyrcona | Think it might be a side effect of the Redis HA branch: WS failed sending data to OpenSRF, exiting |
| 12:34 | Dyrcona | 2026-01-14T12:33:12.084371-05:00 jasontest client: [ERR :35627:transport_connection.c:301:17684119583562717] REDIS Error [NOPERM this user has no permissions to access one of the keys used as arguments] |
| 12:43 | Dyrcona | Might have another vm with plain o'l Redis to test with, but I'm gonna try it with ejabberd first. |
| 12:46 | Dyrcona | Adding a hold note is OK with Ejabberd, so it's definitely Redis. |
| 14:06 | dluch | Question: How does "Shelf Browse" in the staff client determine the call numbers to browse and display? For instance, staff member is looking at a record at the consortium level that has an item they own on it. They use LC call numbers, as do all the other libraries' items on the record except one, which is Dewey. When clicking on Shelf Browse in the record, it only returns Dewey bibs. Why? |
| 14:06 | Dyrcona joined #evergreen |
| 08:43 | mmorgan joined #evergreen | |
| 11:26 | Dyrcona joined #evergreen | |
| 11:39 | jihpringle joined #evergreen | |
| 11:41 | csharp_ | kkk |
| 11:42 | csharp_ | oops - my keyboard test came through :-/ |
| 11:56 | * mmorgan | often types when keyboard focus is not on the intended window and wonders where those keystrokes end up. |
| 11:58 | * Dyrcona | also. |
| 11:59 | * Dyrcona | wants "focus follows brain" for the GUI, but that would likely require an implant that I'm not interested in having. |
| 12:30 | * Dyrcona | makes a copy converted to XML just to see how big it is. |
| 12:31 | Dyrcona | Over 3x bigger.... 194MB versus 63MB. |
| 13:08 | * Dyrcona | will likely be late to the meeting this afternoon. |
| 13:10 | Dyrcona | I'm looking at the Redis HA/LB branch and so far it's working for me in a non-HA/LB environment. I'll comment to that effect on the bug this week. If I knew more about how to set it up, I could probably test it with HA/load balancing. |
| 13:39 | jeff | Was there a list of "we'd like to see more talks about these topics" shared somewhere recently? I didn't see it linked from the CFP, but I could have overlooked it. I know someone recently said "reports". |
| 13:40 | BAMkubasa joined #evergreen | |
| 13:41 | BAMkubasa | Global flag "opac.located_uri.act_as_copy" (When enabled, Located URIs will provide visibility behavior identical to copies.) Anyone have a sense of the implications of turning this on? We were finding that having it off means we can't add e-resource records to a bucket, but weren't sure if we turned it on if there would be other unintended |
| 15:05 | Dyrcona | #info eyes wanted on Redis Stream-based HA/LB branch |
| 15:05 | Dyrcona | #info Dyrcona (me) has been looking at it without load balancing and it's working so far. |
| 15:05 | collum joined #evergreen | |
| 15:06 | Dyrcona | I'll update the bug later this week. I'd like to test it with load balancing if I can figure that out. |
| 15:07 | Dyrcona | I don't think there's much else to say about that, so... |
| 15:07 | Dyrcona | #info csharp_ will look at Debian 13 compatibility |
| 15:07 | Dyrcona | #info That's also done and in the main branches for both Evergreen and OpenSRF. |
| 12:32 | collum joined #evergreen | |
| 12:33 | Dyrcona | So far, it looks like most of these logins do nothing. Does Evegreen create a new session for each tab? What about with an Incognito window? |
| 12:35 | Dyrcona | Ok, this token has actually been used to do something. |
| 12:37 | Dyrcona | I suppose I can test the incognito window theory by logging in myself. |
| 12:41 | Dyrcona | Two or three of the five logins have been doing things, so it must be related to tabs? |
| 12:42 | Dyrcona | So, I logged in with a regular window and opened a couple of tabs. |
| 12:43 | Dyrcona | Only 1 login sessions for me. |
| 15:33 | Dyrcona | So, I'm thinking it's an ad blocker isolating the tabs somehow coupled with the password manager set to autologin. I'll ask the user to check these settings. |
| 15:38 | Dyrcona | I probably won't know anything until Monday given the hour. |
| 15:59 | Dyrcona | Back to the thing I was talking about earlier this week with Redis and action-trigger events: It's definitely the parallel settings and not Redis causing the problem. I've been running the events with parallel off and Redis with no issues. |
| 16:01 | Dyrcona | My SQL to find bad events doesn't find any on the test databases, and the events did run. |
| 16:09 | Dyrcona | Well, so much for the password manager idea. User says that they don't use one. |
| 16:11 | jihpringle joined #evergreen | |
| 17:07 | mmorgan left #evergreen |
| 09:49 | csharp_ | four CPU cores: Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz |
| 09:49 | csharp_ | that's the VM host's processor |
| 09:49 | csharp_ | (fwiw) |
| 09:52 | Dyrcona | csharp_: 16GB RAM, 16 CPUs for the vms where I'm doing my testing. |
| 09:53 | * csharp_ | nods |
| 09:53 | Dyrcona | Bmagic will have to say how the production docker image that does the mark item lost is configured, but I'm considering disabling parallel processing for now. |
| 09:53 | Dyrcona | But, seriously, I will repeat: something is very wrong if it takes more than 16GB of RAM to process 300 to 1,000 events in parallel. |
| 10:06 | pinesol | Dyrcona: What do you mean? An African or European swallow? |
| 10:09 | Dyrcona | "It's not a question of 'ow 'e grips it." |
| 10:09 | Dyrcona | Anyway, what I'm gonna do? Rewrite open-ils.trigger in Rust? |
| 10:34 | Dyrcona | csharp_: I can't find any evidence of the OOM Killer running on either vm where I've been testing this. |
| 10:36 | csharp_ | hmm |
| 10:40 | Bmagic | Dyrcona: your findings agree with my suspicions. The root issue is likely memory management, and when running the same Evergreen code over the top of Redis, it shows the issue more often. Probably* because ejabberd is slower and gives time for garbage collection? |
| 10:53 | Dyrcona | Yeah, but I'm not finding any OOM Killer messages in the logs nor with journalctl. I'm still looking. |
| 15:07 | eglogbot joined #evergreen | |
| 15:07 | Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. Logs for today: http://irc.evergreen-ils.org/evergreen/today | |
| 15:28 | Dyrcona | Ah, the sauce thickens. Parallel or not may not matter with Redis. It looks like I'm getting mark item failures either way there. I'm going to run all of the cron jobs for a day or to after clearing action_trigger.event to see what happens. |
| 15:47 | Dyrcona | OK. Testing tonight and tomorrow will be synchronized with parallel collect and react disabled for open-ils.trigger on both Ejabberd and Redis. Last night's test was with no parallel on Redis and parallel on Ejabberd, both had issues with mark item lost. |
| 16:04 | pinesol | News from commits: LP#2078503: Handle currency symbols in MARC 020$c for acquisitions import <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=91331db6a19ec658560be944979232f47b12b391> |
| 17:00 | mmorgan left #evergreen | |
| 22:49 | pinesol` joined #evergreen |
| 08:32 | mmorgan joined #evergreen | |
| 09:58 | mantis1 joined #evergreen | |
| 10:19 | Dyrcona joined #evergreen | |
| 10:35 | Dyrcona | Ugh. My test was still invalid. The mark item lost/overdue events did not run on one of the two test machines. |
| 10:37 | Dyrcona | However, the numbers are different for auto-renewal events between the two databases, so maybe something happened on the vm with ejabberd? |
| 10:43 | Dyrcona | I am able to reproduce issues with mark item lost events no actually modifying the circulation but the event getting set to complete with Redis and Lp 2116980 applied. |
| 10:43 | pinesol | Launchpad bug 2116980 in OpenSRF "Use Redis STREAMs for HA/LB" [Wishlist,Confirmed] https://launchpad.net/bugs/2116980 - Assigned to Jason Stephenson (jstephenson) |
| 10:57 | collum joined #evergreen | |
| 11:44 | jihpringle joined #evergreen | |
| 13:38 | Dyrcona | I'm starting to suspect that the issue is the parallel settings for open-ils.trigger, and there's a thought in the back of my mind that I came to that conclusion some years ago. |
| 13:48 | Dyrcona | That's something that I can test over the next few days. |
| 13:54 | * Dyrcona | should have stopped to have lunch, but grabs a quick snack before the github meeting. |
| 16:30 | mantis1 left #evergreen | |
| 17:13 | mmorgan left #evergreen |
| 13:46 | sandbergja | hdarcy: yes, we'll meet today |
| 14:26 | jihpringle joined #evergreen | |
| 14:50 | Dyrcona | Ugh. action_trigger_runner doesn't like it if the custom a_t filter you told it to use is missing. |
| 14:51 | Dyrcona | Forgot to copy it to the test machine before testing. |
| 14:55 | Dyrcona | It's maybe too late for the test to be valid. I'll have to try again tomorrow. I'm trying to create a conflict between two a/t jobs: mark item lost and autorenewal. |
| 14:58 | pinesol | News from commits: LP2137146 Staff catalog - record pagination missing borders <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b2614079f273d87e1cf62b1080569e34ab4c6b0c> |
| 14:58 | pinesol | News from commits: LP2137230 Record bucket edit has double arrows by Owner <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1cdbd118eb1ced42d54d8fcfc26198f881359d0d> |
| 14:58 | pinesol | News from commits: LP#2137056: fix open-in-new-tab behavior of Staff Portal page <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0db121b4bf6d2e307cbf1020aa073ab829c43562> |
| 08:38 | mmorgan joined #evergreen | |
| 09:08 | Rogan joined #evergreen | |
| 11:03 | Dyrcona joined #evergreen | |
| 13:45 | Dyrcona | Guess I'll have to wait until next week to run my tests. The copy of production data that I have on my test system is too old to test autorenewals and things like that. |
| 13:45 | Dyrcona | It should get refreshed this Sunday. |
| 16:57 | mmorgan left #evergreen | |
| 20:36 | eglogbot joined #evergreen |
| 13:59 | mantis2 left #evergreen | |
| 14:36 | csharp_ | goood++ # bug 2133878 |
| 14:36 | pinesol | Launchpad bug 2133878 in Evergreen "Store user session data in the database rather than in memcached" [Wishlist,In progress] https://launchpad.net/bugs/2133878 - Assigned to Mike Rylander (mrylander) |
| 14:40 | goood | csharp_: if you are just bored over the break and want to test that out ... that'd be super awesome |
| 14:40 | goood | oh, I need to remove me from the bug assignment! |
| 14:41 | goood | done |
| 14:49 | goood | csharp_ / Dyrcona: re rule explosion, I have a proposal (have had for ... 12 years) to address that in the form of field comparison rather than value comparison. "this rule is a match if the copy circ_lib and user home_ou are the same (range adjusted)" instead of "if circ_lib = 3 and home_ou = 3" |
| 14:50 | csharp_ | goood: where do I +1? :-) |
| 14:50 | goood | but ... no funding has come through. just considered a nice-to-have, I guess, once the static rules are written |
| 14:50 | goood | csharp_: well, you just sign this contract right here, and ... ;) |
| 15:28 | csharp_ | works so far - able to register workstation, move around, and I see the session in the new table |
| 15:28 | goood | woot. it's been working on my dev machine for a month, so ... I'm not TOO surprised, but glad for the basic confirmation! |
| 15:29 | csharp_ | noice |
| 15:33 | goood | it shifts load from memcache to pg, of course, so some real stress testing is in order. (do I want to double-buffer? use pg as L2 and memcache as L1? no I do not. see: the 2 hard things in compsci) |
| 17:05 | mmorgan left #evergreen |
| 04:49 | Guest76 | I have a question about Evergreen. I'm trying to find the capacity of storage that it has for documents but I do not find it at all. Can you tell me how much capacity it has. We would like to do a migration but we have a lot of data. |
| 04:49 | Guest76 | Cordially. |
| 06:47 | Guest22 joined #evergreen | |
| 08:28 | csharp_ | shutting down docs-testing for some server-level changes... |
| 08:34 | mmorgan joined #evergreen | |
| 08:45 | Rogan joined #evergreen | |
| 08:47 | csharp_ | running long-needed APT updates/upgrades |
| 09:19 | csharp_ | okay - back up, running Debian bullseye (EOL 8/26) |
| 09:19 | csharp_ | any docs-ers who want to poke at it will be appreciated |
| 09:20 | csharp_ | looks like we need an SSL cert set up for that server |
| 09:38 | Dyrcona | Bmagic | berick: I wonder if this issue that CWMARS is having with mark item lost action triggers is related to using Redis instead of Ejabberd? |
| 10:04 | mghaight joined #evergreen | |
| 10:17 | mmorgan | Is the DEV meeting today at 3:00(eastern) as usual? Some confusion is afoot as the minutes of last month's meeting say Dec. 12th. |
| 10:33 | * Dyrcona | runs the processes on a test vm with Redis and a copy (more or less) of the production opensrf.xml file to test that idea. |
| 10:34 | Dyrcona | mmorgan: it's on the community calendar for today, so I would think it is today. |
| 10:35 | * mmorgan | agrees |
| 10:35 | mmorgan | Dyrcona++ |
| 10:46 | Dyrcona | And, I think the problem could be related to Redis and our configuration. I can reproduce the issue on a vm with that configuration. I'll test it on one with Ejabberd to see if it also happens there. |
| 10:52 | mghaight joined #evergreen | |
| 11:00 | Dyrcona | Just for the logs/interest: On my test system with Redis, mark item lost did 740 events, and 20 of them failed to mark the item lost. These are still checked out as far as Evergreen is concerned, and not set the lost or any other "state." |
| 11:00 | Dyrcona | The events are all in state "complete." |
| 11:01 | Christineb joined #evergreen | |
| 11:13 | Dyrcona | On the Ejabberd vm, all of the mark item lost events actually marked the items as lost. |
| 11:15 | Dyrcona | oops. made an edit with sed and changed too much. |
| 11:33 | jihpringle joined #evergreen | |
| 11:48 | Bmagic | Dyrcona: yes, it's possiblely related actually. |
| 12:04 | Dyrcona | Bmagic: I'm sure it's related after running the tests. |
| 12:05 | Dyrcona | I've opened a ticket with our hosting provider. :) |
| 12:06 | * Dyrcona | will likely be late to the dev meeting today. |
| 13:15 | mghaight joined #evergreen | |
| 13:22 | Bmagic | I won't be able to make the meeting today |
| 13:31 | * Dyrcona | assigned Lp 2116980 to himself, but then realized it is doing something that won't be so simple to test. It also likely won't fix my current issue. |
| 13:31 | pinesol | Launchpad bug 2116980 in OpenSRF "Use Redis STREAMs for HA/LB" [Wishlist,New] https://launchpad.net/bugs/2116980 |
| 13:44 | mdriscoll joined #evergreen | |
| 14:05 | Dyrcona | Yeah, I will be late for the meeting. Hopefully, I'll be back by the time we get to new business. I expect the meeting will be lightly attended anyway. |
| 15:05 | jeff | And thus, Docker was born. |
| 15:06 | shulaprime | lol jeff++ for beating me to the joke. |
| 15:06 | goood | ew, jeff. ew. |
| 15:06 | jeff | miker: is everything needed to test/eval included in that bug? |
| 15:06 | * jeff | belatedly realizes why his attempts to tab-complete "miker" were failing... |
| 15:07 | goood | jeff: should be, yes. the key is --reset-message-bus --hard to start |
| 15:07 | mmorgan | #info mmorgan = Michele Morgan, NOBLE |
| 15:08 | shulaprime | the vibe i'm getting is we should revisit this next month when there are more eyes; a situation i'm sure is likely during the holiday season ;) |
| 15:09 | shulaprime | goood++ |
| 15:09 | shulaprime | #action eyes wanted on Redis Stream-based HA/LB branch (https://bugs.launchpad.net/opensrf/+bug/2116980) |
| 15:09 | pinesol | Launchpad bug 2116980 in OpenSRF "Use Redis STREAMs for HA/LB" [Wishlist,New] |
| 15:10 | goood | @later tell Dyrcona was your earlier redis test with my branch or current main? |
| 15:10 | pinesol | goood: The operation succeeded. |
| 15:10 | goood | (for the "more eyes" tally) |
| 15:10 | shulaprime | #topic csharp_ will look at Debian 13 compatibility |
| 15:25 | shulaprime | jeff++ mmorgan++ gmcharlt++ |
| 15:26 | abneiman | gmcharlt++ mmorgan++ |
| 15:26 | abneiman | I'll give another day or two for other volunteers then I'll send out an email |
| 15:26 | * mdriscoll | will test tarballs |
| 15:26 | abneiman | mdriscoll++ |
| 15:26 | shulaprime | abneiman++ sounds like a plan |
| 15:26 | shulaprime | mdriscoll++ |
| 15:38 | Dyrcona | goood: I was using Redis main. There are problems with a/t events among other things. |
| 15:38 | goood | Dyrcona: I've seen main drop messages, but my current branch isn't doing that for me. but ... more eyes! |
| 15:39 | goood | (and to be clear, /mine/ was dropping messages at one point, but no longer) |
| 15:40 | Dyrcona | Well, I realized your changes are about load balancing, and that was not something I'm prepared to test right now. Maybe in a bit. |
| 15:40 | goood | it works in all-on-one-server mode, of course |
| 15:43 | Dyrcona | Yeah. I'll give it a try. I want to figure out what bugs Redis is uncovering so we can fix these issues. |
| 15:49 | goood | Dyrcona++ |
| 13:46 | Dyrcona | I found another case of "we're doing it wrong." |
| 13:48 | Dyrcona | https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Circulate.pm;h=e20473162ac427698d6f0de691afa9c55b3adf97#l1762 |
| 13:49 | Dyrcona | from perldoc -f ref: It is a common mistake to use the result of "ref" directly as a truth value: this goes wrong because 0 (which is false) can be returned for a reference. |
| 13:50 | Dyrcona | However, we may not want to change the status in that case. Also, I'm not sure that's quite the proper use of ref. I'd have to write a test program. |
| 13:52 | Dyrcona | I've also spent only about 30 minutes looking at this today, so I could be off. |
| 13:56 | Dyrcona | OIC. |
| 14:39 | kmlussier joined #evergreen |
| 12:27 | Dyrcona | csharp_++ That's the main argument for merge in my opinion. |
| 12:27 | jonadab | That makes sense to me. |
| 12:27 | Dyrcona | jonadab: Yeah, cherry-pick makes it easy to get individual commits and that's its main purpose as far as I can tell. |
| 12:28 | csharp_ | when I'm testing something, I like seeing the pile of commits on top, and that seems to be the main point in favor of patch workflow |
| 12:28 | csharp_ | but there are ways to sort git log too |
| 12:28 | Dyrcona | When I get really desperate, I'll sometimes generate patches from git and apply them in another branch with `git am` |
| 12:29 | * Dyrcona | confesses to editing patches occasionally to remove stuff I don't want. |
| 12:30 | Dyrcona | All of that being said, I'm not sure there's a workflow that easily reconciles code drift like we're looking at with eCard. |
| 12:32 | gmcharlt | missing from the instructions: set the added content base_url to https://content.chilifresh.com/ |
| 12:35 | gmcharlt | force-pushed to the working branch to remove the extra warn and to clarify that base_url needs to be set |
| 12:45 | Dyrcona | OK. I base_url is likely the problem. I was able to get cover images with cURL when I tried last week. |
| 12:46 | Dyrcona | A force push makes trying the changes more difficult since I've already cherry-picked in the branch I'm testing. I'll just set base_url and see what happens. |
| 12:50 | Dyrcona | gmcharlt++ That was it. I set base_url and it works! |
| 13:01 | csharp_ | Dyrcona: whoooo |
| 13:01 | csharp_ | gmcharlt++ |
| 10:46 | Dyrcona | The brownser and Zoom see that the camera is there. They just get no output. The Camera app works until you stop the camera, then it won't turn it back on. |
| 11:02 | Bmagic | browser mic/camera passthru is funky |
| 11:09 | Dyrcona | I think it's lingering IPU6 issues. I couldn't find anything that says my particular laptop would still be a problem, but some Alder Lake laptops still have camera issues with kernel 6.17. |
| 11:12 | Dyrcona | Is anyone using Chilifresh with Evergreen? I tried setting it up on a test system, and even though we have a free trial setup, it's not working. I get no cover images. |
| 11:13 | Dyrcona | I "corrected" the URL to what Chilifresh redirects to, and If I retrieve that with cURL, I do get something that looks approximately correct. |
| 11:14 | Dyrcona | I think we're going to have to update the API. Chilifresh has a cover image API, and if I hit the cover art URL for an ISBN directly, I do get an image. (Again, with cURL.) |
| 11:15 | Dyrcona | I've been in contact with Chilifresh, but haven't heard anything since last Wednesday. I suspect time off on both sides may be a factor. |
| 13:38 | Dyrcona | auth_internal, too. No failed services, either. |
| 13:43 | Dyrcona | I am able to login via the OPAC. |
| 13:43 | Dyrcona | Let me try again. I have restarted services since I got the error. Maybe it was just one of those things. |
| 13:44 | Dyrcona | Woah. I hit my bookmark for the staff client on this test machine, and I'm logged in..... |
| 13:44 | Dyrcona | Goes straight to the splash page. |
| 13:45 | Dyrcona | I'll log out and see what happens when I log in again. |
| 13:46 | Dyrcona | It's working. I must have just needed to restart services or soemthing. |
| 15:33 | csharp_ | maybe just as a thought experiment |
| 15:33 | jihpringle joined #evergreen | |
| 15:33 | csharp_ | Bmagic: sipping on my Fretboard coffee :-) |
| 15:38 | Dyrcona | Hm... tests failing with a 401 but expecting a 403, that's probably an Apache configuration difference. |
| 15:43 | Dyrcona | yeahp. That was it. |
| 15:45 | csharp_ | A Patchy Webserver |
| 15:45 | csharp_ | sometimes I want ansible to be more bash-y |
| 16:00 | Bmagic | they do good work |
| 16:00 | Bmagic | It's like a new toy |
| 16:02 | Bmagic | csharp_++ # Fretboard |
| 16:05 | Dyrcona | Running the nightwatch tests for eg2 seems to take a while. |
| 16:08 | goood | csharp_: yes, no more external password files! also, I think we can move the redis admin password into opensrf_core.xml (in addition to redis.conf, obv) rather than storing it externally or passing it on the command line or in the env. that would simplify things even more. |
| 16:08 | * csharp_ | nods |
| 16:09 | goood | (and, speaking of "goood's branch", it's updated now with leak fixes and ready for more testing, if anyone is feeling saucy) |
| 16:09 | csharp_ | @band add Sassy's Sassiest Boys |
| 16:09 | pinesol | csharp_: Band 'Sassy's Sassiest Boys' added to list |
| 16:10 | csharp_ | @dunno add Sprechen zie Sassy? |
| 16:10 | pinesol | csharp_: The operation succeeded. Dunno #103 added. |
| 16:24 | Dyrcona | I wonder if anything is actually happening with the nightwatch tests. I probably have to set the tmp directory because snaps... |
| 16:29 | Dyrcona | Did that and now my vm is actually doing something. |
| 16:31 | JBoyer | Mentions of ansible having caught my eye: there's no need to do almost anything with a shell command (except install python pre-reqs or something that low level) |
| 16:32 | JBoyer | lineinfile is extremely useful for line editing (when just using template or file isn't better) |
| 16:38 | Dyrcona | Yeah, setting TMPDIR got the tests to work. |
| 16:44 | csharp_ | JBoyer++ |
| 16:47 | abneiman | merge pause is lifted, point releases are out |
| 16:50 | abneiman | gmcharlt++ mmorgan++ Bmagic++ mdriscoll++ |
| 15:04 | sandbergja | Dyrcona: you asked if anybody had a fix for `npm install -g @angular/cli@^15.0`? There's a fix at bug 2096711 -- it's not a needed step, so in my opinion, the fix is to simply remove that step |
| 15:04 | pinesol | Launchpad bug 2096711 in Evergreen "Don't install @angular/cli globally" [Undecided,New] https://launchpad.net/bugs/2096711 |
| 15:06 | * Dyrcona | had no idea that step was superfluous, but guess it is. |
| 15:19 | Dyrcona | Think I'll take that bug, too, and give it a whirl on a test vm. |
| 15:22 | Dyrcona | Bmagic: You updated a related bug with a comment describing what I'm seeing exactly 1 year ago today: https://bugs.launchpad.net/evergreen/+bug/2080794/comments/3 |
| 15:22 | pinesol | Launchpad bug 2080794 in Evergreen "Upgrade nodejs to 22" [Undecided,Fix released] |
| 15:45 | Bmagic | oh! I do remember writing that now that you mention it |
| 11:59 | jihpringle joined #evergreen | |
| 12:15 | jihpringle joined #evergreen | |
| 12:33 | jihpringle joined #evergreen | |
| 15:12 | pinesol | News from commits: LP2045073 follow-ups: update angularjs condition and add angular unit test <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c3140c60fc0be9ae1aa03ced4d15bbf2505986f3> |
| 15:12 | pinesol | News from commits: LP2045073 Disable print, download CSV on empty grids <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=059e3f0aabf2a02ed3ea94e0ff66329435a0dde4> |
| 16:42 | pinesol | News from commits: Docs: SIP filter documentation <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fb4959fec943baf9ef1057354b0e5e17634139ec> |
| 17:04 | mmorgan left #evergreen | |
| 17:38 | scottangel joined #evergreen |
| 15:33 | BDorsey joined #evergreen | |
| 15:37 | BDorsey | Howdy, all! Question: Does the demo server have an account with buckets that were previously deleted? We're making the switch to 3.15+ and many (if not all) of my deleted buckets are showing up in the angular record buckets module. Once you delete it in 3.15, it's gone, but they shouldn't be there in the first place, right? |
| 15:37 | BDorsey | I was hoping to confirm on the demo server, but I'm not seeing any buckets on the admin account. |
| 16:11 | mmorgan | @later tell BDorsey The concerto data set that gets loaded into test and demo systems does not have any buckets by default, so there isn't a way to test that on the demo server. |
| 16:11 | pinesol | mmorgan: The operation succeeded. |
| 16:25 | gmcharlt | jeffdavis: not necessarily |
| 16:26 | gmcharlt | i.e., one can continue to do cherry-picking, and if one is working directly through GitHub, it provides options to force doing linear rebase + cherry-picks rather than merge commits |
| 15:09 | dluch | #info dluch = Debbie Luchenbill, MOBIUS |
| 15:09 | JBoyer | #info JBoyer = Jason Boyer, EOLI |
| 15:09 | Bmagic | #info Bmagic = Blake GH, MOBIUS |
| 15:09 | gmcharlt | #info the RediSRF stream based has received testing during the hack-a-way; various bugfixes under way |
| 15:10 | Rogan | #info Rogan = Rogan Hamby, EOLI |
| 15:10 | gmcharlt | #info The Debian 13 compatibility branch has been committed to main |
| 15:11 | ying_h | #info ying_h Ying-Hsiang Huang, KCLS |
| 15:57 | gmcharlt | so I'm curious how much appetite there is for doing an extra normal bugfix release for 3.14 |
| 15:58 | abneiman | I put it in because I wasn't sure what the sense was about that |
| 15:58 | Dyrcona | Are there sites running 3.14 that would upgrade to 3.14.12? |
| 16:00 | abneiman | I'm not seeing anything critical on 3.14.12, and the one High-importance bug might be invalid at this point anyway (needs more testing tho IMO) |
| 16:00 | dluch | I'd say cut it off, then |
| 16:00 | abneiman | that being lp 2107346 |
| 16:00 | pinesol | Launchpad bug 2107346 in Evergreen 3.15 "Enhanced MARC Editor - Field tags, indicators, and subfield tags not saving consistently" [High,Incomplete] https://launchpad.net/bugs/2107346 |
| 16:09 | abneiman | lp 2122539 |
| 16:09 | pinesol | Launchpad bug 2122539 in Evergreen "Copy attribute unsetting fails for number-ish fields" [Critical,Confirmed] https://launchpad.net/bugs/2122539 |
| 16:09 | abneiman | thank you pinesol |
| 16:12 | JBoyer | good news re: 2122448, there's an alternative branch being tested now that fixes a couple things. With that out of the way I was planning to look into 2122539. |
| 16:12 | abneiman | JBoyer++ |
| 16:13 | mmorgan left #evergreen | |
| 16:18 | goood | https://bugs.launchpad.net/evergreen/+bug/1954937 |
| 13:42 | smoodyECDI left #evergreen | |
| 13:55 | gmcharlt | claiming 1501 and 1502 |
| 13:57 | csharp_ | berick: same here |
| 14:18 | pinesol | News from commits: LP#1847805,2098043,2098407,2098117: stamp database updates <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0b1ce3cf65cddf5d923c732107b29f6e8ce9ca2e> |
| 14:19 | pinesol | News from commits: LP#1847805: (follow-up) correct number of test cases <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=dd5036c1acb46edceb2e03ddf932db27c84d7a4b> |
| 14:19 | pinesol | News from commits: LP#2098043,2098407,2098117: Angular Bucket updates <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=38a46cb3905719e4800176f6f7f66eee0ca2b9c7> |
| 14:19 | pinesol | News from commits: LP#1847805: in-query pcrud perm checks <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9301601b4684929e4eca3921916476db599fc208> |
| 14:40 | gmcharlt | noting that what I just commit makes it an even BETTER idea than normal for folks to test the RC (which will be announced after some further smoke-testing today) |
| 14:53 | csharp_ | gmcharlt++ |
| 15:19 | pinesol | News from commits: LP#2098043,2098407,2098117: (follow-up) de-lint <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8b5add12242ab10226424726443bfb7adf378f48> |
| 17:02 | mmorgan left #evergreen |
| 11:57 | eeevil | no, it's not the built-in browser cache |
| 11:57 | eeevil | it's the indexeddb cache that we build |
| 11:58 | Bmagic | I see, so I would see the websockets request, just after the request, somewhere before firing off the request over the internet, it supplies the answer internally? |
| 12:01 | * csharp_ | appears |
| 12:03 | csharp_ | abneiman: I go by this (or my working memory of it): https://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq |
| 12:03 | csharp_ | Incomplete - The bug report is missing important information preventing it from being fixed. The submitter should be notified to provide additional information. |
| 12:03 | csharp_ | Won't Fix - Bug will not be fixed. Reasons may vary. |
| 12:04 | csharp_ | in the case of bug 2130454, jihpringle tested and could not reproduce, so I marked Incomplete |
| 12:04 | pinesol | Launchpad bug 2130454 in Evergreen "Holdings View tab: "Show" checkboxes aren't sticky" [Undecided,Incomplete] https://launchpad.net/bugs/2130454 |
| 12:05 | csharp_ | similar situation with bug 2107346 - the most recent comments indicate they aren't seeing the reported issue |
| 12:05 | pinesol | Launchpad bug 2107346 in Evergreen 3.15 "Enhanced MARC Editor - Field tags, indicators, and subfield tags not saving consistently" [High,Incomplete] https://launchpad.net/bugs/2107346 |
| 12:06 | csharp_ | also, just for the record, I'm cool with other people deciding that I'm wrong about choosing a status, etc. - it actually kind of happens a lot :-) |
| 12:06 | csharp_ | I just don't want to keep a bug in "New" or "Confirmed" if it doesn't appear to still be a real bug in recent testing |
| 12:07 | csharp_ | </my_opinion> |
| 12:08 | csharp_ | agreed that a review of statuses/wrangling expectations would be useful |
| 12:11 | abneiman | csharp_++ |
| 12:11 | abneiman | thanks! |
| 12:14 | csharp_ | re: 11:45 < Bmagic> Maybe "invalid" "feels" too harsh. And it would make the bug report-person feel invalidated :) |
| 15:39 | csharp_ | yeah, obviously have zero investment beyond this discussion :-) |
| 15:40 | Bmagic | I'm verifying that deleting a bib (via delete from biblio.record_entry) will trigger-delete the volumes |
| 15:43 | Bmagic | it does not |
| 15:45 | Bmagic | I'm testing that little switcharoo in the $vols check |
| 15:49 | Bmagic | I think it's well overdue that Evergreen automatically delete it's URI's when BRE is deleted |
| 15:50 | Bmagic | imma fix it |
| 15:52 | Bmagic | found a couple old related bugs: https://bugs.launchpad.net/evergreen/+bug/761085 https://bugs.launchpad.net/evergreen/+bug/761130 |
| 19:15 | jihpringle joined #evergreen | |
| 19:48 | jihpringle joined #evergreen | |
| 21:24 | sandbergja joined #evergreen | |
| 22:03 | pinesol | News from commits: LP1902937 follow-up: update bootstrap 4 class to bootstrap 5 class <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=584a6610a75105c32e52d8e130c3e9185d645f69> |
| 22:03 | pinesol | News from commits: LP2032665: follow-up: get unit tests compiling again <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=224c4f22cb7d54ac44a763ba1f7cb7f056b390df> |
| 23:24 | stephengwills joined #evergreen |
| 09:45 | redavis joined #evergreen | |
| 10:12 | berick | Dyrcona: FYI i'm probably canceling the Rust session today so I can try to do some regular EG stuff |
| 10:15 | redavis | berick++ |
| 10:16 | eeevil | Bmagic: cursors came in with commit 19984921b8. they make it possible (like, at all, period) to handle certain shapes of data via prcud, given the current "test each row after fetching" logic. the FETCH is equivalent to a SELECT, and is the "give me the first 100 rows" request of the associated DECLARE ... SELECTs plan. the underlying query plan will be the same (or better, cursors tell PG to use a plan that should return the first row faster, rather |
| 10:16 | eeevil | than the whole query faster). tl;dr: you can ignore the fact of the fetches, just look at the DECLARE ... SELECTs for investigation. relatedly, the branch at the end of https://bugs.launchpad.net/evergreen/+bug/1847805 actually disables cursors in favor of direct limit/offset because it pushes access restrictions into the query instead of fetch-then-test. that branch, btw, shows a 2-10x speedup in statistically-measurably-long (more than a few ms) |
| 10:16 | eeevil | queries in my testing. |
| 10:16 | pinesol | Launchpad bug 1847805 in Evergreen "pcrud search can fail to retrieve rows that the user has access to" [High,Confirmed] |
| 10:19 | Dyrcona | berick: OK. I haven't had a chance to look at much of anything Rust-related since the last meeting. |
| 10:30 | mantis left #evergreen |
| 11:32 | csharp_ | yeah, we upped it to allow for better planning - again, meh |
| 11:32 | Bmagic | right, I've reviewed that setting in the past |
| 11:32 | csharp_ | eeevil almost certainly has better ideas about how to set things like that |
| 11:32 | Bmagic | it doesn't explain the test machines not having an issue |
| 11:32 | csharp_ | (pretty sure he was the one to point me to that setting in the past) |
| 11:33 | * eeevil | reads up... |
| 11:34 | csharp_ | if it's literally the same plan on test/development/production/whatever, then the stats stuff might be a red herring |
| 11:36 | csharp_ | having run PG on multiple types of machines/VMs/environments, I can say that some of the differences I've seen can only be attributed to the supernatural :-) |
| 11:36 | Dyrcona | It's not the same plan. It's the same query and different data, about 200 rows less in development. |
| 11:36 | Bmagic | My theory is the plan is different between the two. The databases are identical in terms of general size and shape of the tables involved. call number 1717933 happens to be one with lots of connections |
| 11:37 | csharp_ | select * from pg_ghost; |
| 11:38 | eeevil | I'm confused about what is being tested here |
| 11:39 | Bmagic | eeevil: click the "query" tab on those explains |
| 11:39 | eeevil | I did |
| 11:39 | Dyrcona | I was leaning in the direction of tweaking the query planner. It's using more indexes in development and doing more scans in production. |
| 11:54 | Dyrcona | Removing the coalesce speeds it up. |
| 11:54 | Dyrcona | AND acp.circ_lib IN (SELECT id FROM actor.org_unit_descendants((evergreen.org_top()).id)); |
| 11:55 | Dyrcona | Why are we doing the coalesce? Are there cases where org_top() could return null? |
| 11:57 | eeevil | Dyrcona: we're NOT, in the actual function |
| 11:57 | eeevil | we're passing $2, an optional (default NULL) org id |
| 11:58 | eeevil | interestingly, we're not testing that the acn is not deleted. no biggie, IMO, but ... odd |
| 11:58 | Bmagic | right, the function needs to accomodate an OU |
| 11:58 | Dyrcona | Hm. I'll look at the actual function, then. I thought Bmagic was testing a verbatim copy/paste with values plugged in. |
| 11:59 | Bmagic | Dyrcona: exactly, copy/pasted the function and plugged in null for the OU, and the ID number for the bib |
| 11:59 | Dyrcona | Well, if the acn is deleted, it should have all deleted copies, so if the copy isn't deleted, then neither should the acn be deleted. |
| 12:00 | Dyrcona | Well, eeevil said the function doesn't do the coalesce... So I'll still have to look at the function. |
| 12:03 | eeevil | (and yes, re acn.deleted, acp.deleted is a pretty safe proxy) |
| 12:03 | Bmagic | bug 2129571 |
| 12:03 | pinesol | Launchpad bug 2129571 in Evergreen "asset.record_has_holdable_copy can be slow" [Undecided,New] https://launchpad.net/bugs/2129571 |
| 12:05 | eeevil | Bmagic: https://lumen.esilibrary.com/p/HBAe8E30.html if you want to test my first-order patch above ... works for me |
| 12:06 | Dyrcona | eeevil: I guess I didn't understand something you said earlier or whatever, but I can say that removing the coalesce makes it faster on our production database. The development database doesn't care and they should be about the same, execpt for settings. |
| 12:07 | Bmagic | eeevil++ # testing |
| 12:07 | Dyrcona | With an ou id, the coalesce doesn't seem to make a difference. |
| 12:08 | eeevil | Dyrcona: ah, I confused things, pardon. I should use all my words. |
| 12:08 | pinesol | News from commits: Docs: 3.15.6 release notes <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=11842140c303686b69042ff9e32bd908b24ed042> |
| 12:17 | eeevil | something about putting the function there (as a coalesced param to another function) is convincing the planner that scanning the tables /in toto/ will be faster than maybe calling the function. it may depend on the stats related to the first bib used, but that's unlikely. I think it's a planner reasoning issue in param-nested functions in a plan that has to work for both NULL and NOT NULL cases, so it probably CANNOT optimize the call away, ever. ( |
| 12:17 | eeevil | different versions of PG obviously have different optimizations for function cached plans, so 16 may be smart enough for the old version) |
| 12:17 | Bmagic | abneiman++ |
| 12:18 | Dyrcona | eeevil: Both of the databases where I'm testing this are Pg 16, and they show radically different performance. |
| 12:18 | eeevil | Bmagic: well, not the whole function. just the filter we're focusing on. there's no difference between "and is in the FULL list of orgs" and just not asking if it's in the full list |
| 12:19 | eeevil | Dyrcona: ah, well, I dunno then. |
| 12:19 | eeevil | stats, jit, work_mem, parallel workers, etc |
| 12:23 | eeevil | it would be nearly as fast (to the point of no measurable difference, I'd wager) and more maintainable to just build an array of orgs and use "= ANY" |
| 12:23 | Dyrcona | IIUC, that function is looking for any holdable copies at the org unit or at any of its descendants, so you want the select on actor.org_descendants() in either case. |
| 12:23 | Bmagic | if you don't specify a circ_lib, it's all circ_libs |
| 12:24 | eeevil | Dyrcona: only if there is an ou passed in. if ou is NULL, we use all orgs for the "is it here" test. that's the same as not asking the question -- it's always true |
| 12:24 | Dyrcona | What would make sense, and maybe I missed a comment to that effect, would be to set an array variable at the top and then use the ANY in the query. We could probably use ANY even in the current form. |
| 12:25 | Dyrcona | eeevil: Yes, I elided that bit thinking it was obvious. |
| 12:25 | Dyrcona | Maybe I should use all the words, but verbosity is a drag. |
| 12:29 | eeevil | Dyrcona: I believe we have all arrived on the same page from different edges |
| 12:29 | Dyrcona | eeevil++ |
| 12:31 | Bmagic | https://pastebin.com/nLv3zzVf |
| 12:31 | Bmagic | I just put that function on my test machine and it dropped the execution time from 2.2ms to 1.3ms |
| 12:32 | Bmagic | I lifted the exact logic from eeevil's comment above |
| 12:35 | Dyrcona | Bmagic: I don't like it. Running different code based on the second input variable being NULL is a maintenance bug waiting to happen. |
| 12:36 | Bmagic | I can see that, offer the ANY version |
| 12:47 | csharp_ | @dunno add I WANT MY TWO DOLLARS! |
| 12:47 | pinesol | csharp_: The operation succeeded. Dunno #101 added. |
| 12:47 | Dyrcona | Well, I think eeevil's original solution is fine. If we want to got the ANY route, then I prefer mine. :) |
| 12:47 | Bmagic | FWIW, on my test machine: ANY = 8ms, eeevil's single = 2.1ms, split IF = 1.2ms |
| 12:48 | Dyrcona | Yeahp. Is .9ms worth a potential maintenance issue? |
| 12:48 | Bmagic | nope, I don't think so |
| 12:49 | Bmagic | plus, it's slower when provided a second argument |
| 12:50 | eeevil | oh, nm, Dyrconasaid that |
| 12:50 | Bmagic | happy to do that |
| 12:50 | Bmagic | which one are we going with? |
| 12:50 | Dyrcona | On my test database, the ANY version is 4.777ms. |
| 12:51 | Bmagic | and race it against eeevil's original |
| 12:51 | Dyrcona | And the original is 3.763ms.... :( |
| 12:51 | Bmagic | the original, original? or eeevil's original proposed fix? |
| 12:51 | eeevil | which function? the one with the least amount of maintenance overhead is my preference. if single-query =ANY is as fast as my first one, go with =ANY. |
| 12:52 | eeevil | (because =ANY /can/ be faster, even if it's not always) |
| 12:52 | Bmagic | they are super close in speed, with ANY taking an additional 1ms (sometimes) |
| 12:54 | Bmagic | I just tested a bunch of random integers as the second argument. The ANY performs the same as eeevil's OG |
| 12:55 | Bmagic | I'm leaning towards ANY |
| 12:55 | Dyrcona | OK, go with ANY. |
| 12:55 | Bmagic | was there a nit pick on the variable name from Dyrcona's paste? |
| 12:58 | Dyrcona | It's the old way of addressing parameters in functions. We've upgraded past any version that does not support named parameters. |
| 12:58 | Bmagic | my $annoy_eeevil_crazy_name; |
| 12:59 | jeff | and I misremembered. it's only in the method name now (or only ever was). |
| 12:59 | Dyrcona | On my test database, eeevil's implementation outperforms the any version without a second parameter almost every time. |
| 13:02 | csharp_ | jeff++ # I had the same thought about crazy search |
| 13:04 | jihpringle joined #evergreen | |
| 13:06 | Bmagic | https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/lp2129571_slow_asset_record_has_holdable_copy |
| 13:39 | Dyrcona | I wonder if the problem is the coalesce inside the function parameters? |
| 13:40 | Dyrcona | Both of them get slower when I add a second argument, and the non-any version still takes almost twice as long. |
| 13:41 | Dyrcona | Grrr.... The any version takes about twice as long as the non-any version: 58.664 ms vs. 25.795 ms. |
| 13:48 | Dyrcona | So, I'm putting the any version in production. Testing on one record really isn't very scientific, and I agree that ANY on a pre-fetched array can be faster than IN against a query. |
| 13:59 | Dyrcona | Bmagic++ |
| 13:59 | Dyrcona | eeevil++ |
| 14:08 | Dyrcona | I have another implementation to test that mixes the two approaches. It uses eeevil's original code to set a v_ou variable and then uses that variable to retrieve an array of ous. We'll see if that's faster. |
| 14:15 | Dyrcona | Nope. eeevil's original suggestion is still faster. |
| 15:00 | Bmagic | A hole in one we would say! eeevil++ miker++ Dyrcona++ |
| 15:44 | mantis left #evergreen |
| 14:55 | csharp_ | ok, so probably not kernel |
| 14:55 | Bmagic | yeah, that number is so large, I can't imagine it's imposing any restrictions |
| 14:56 | csharp_ | maybe play with setting shared_buffers during off hours and see if anything changes?\ |
| 14:56 | Bmagic | I'm hopeful it's shared_buffers. I have a test machine with the same database on it, I'll increase the buffer to 192, and see if it's slow, then back to 8GB |
| 14:58 | csharp_ | https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY - note the advice about that setting |
| 14:58 | csharp_ | also that it requires a restart |
| 14:58 | csharp_ | sorry, probably over-advising |
| 13:31 | pinesol | News from commits: LP2102049 ARIA counts for grid action buttons <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ecd1d5f8d769f2a44b41cc9b3ae1773fcbf905eb> |
| 14:01 | pinesol | News from commits: LP2087870 Transit destination shortname <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1c6692b5fe017689ee4b3f57400793c7301e9e0a> |
| 14:31 | pinesol | News from commits: lps-2116206-2116127-2116129: Add initials input field and validation to note dialog <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e1cd685044166890d3ac090601d3ca884c982f71> |
| 15:05 | sandbergja | Bmagic and anybody else who wants to help with the nightwatch tests: bug 2129093 |
| 15:05 | pinesol | Launchpad bug 2129093 in Evergreen "Nightwatch tests are failing on main" [Undecided,New] https://launchpad.net/bugs/2129093 |
| 16:01 | pinesol | News from commits: LP1949222 Add to basket action in record view <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b12f65c8a8e5a40450d7e45561c7d4cd80337fa3> |
| 16:09 | Bmagic | sandbergja++ |
| 16:44 | terranm joined #evergreen | |
| 17:03 | mmorgan left #evergreen |
| 15:10 | mmorgan | redavis++ |
| 15:11 | shulabramble | anyone have any other notes on updates for OpenSRF, etc? |
| 15:11 | Dyrcona | is it too late to sneak in support for Debian 13? |
| 15:11 | csharp_ | Dyrcona: testing that is on my to-do this week |
| 15:12 | Dyrcona | csharp_++ |
| 15:12 | shulabramble | csharp_++ |
| 15:13 | shulabramble | okay, wall o' text incoming. |
| 15:17 | csharp_ | Dyrcona: we do, very happily |
| 15:17 | eeevil | right now, I think there is a segfault or use-after free when ALL services are dereg'd, causing the routers to croak. otherwise, it's been working well for me in my dev env for ~3mo |
| 15:18 | shulabramble | csharp++ pines_team++ |
| 15:18 | Dyrcona | I have no trouble in dev. In prod or testing we quickly run out of drones. |
| 15:18 | eeevil | in particular, I would like to invoke berick's name ... he def knows the redis rewrite's guts best |
| 15:19 | csharp_ | @seen berick |
| 15:19 | pinesol | csharp_: berick was last seen in #evergreen 5 days, 5 hours, 38 minutes, and 6 seconds ago: <berick> Dyrcona: heh, you tell me. my 2006 goggles are on the fritz |
| 15:20 | Dyrcona | No, I don't think we're going cross domain. |
| 15:20 | eeevil | kk |
| 15:20 | csharp_ | we are not cross registering - just single app servers that don't know about the others |
| 15:21 | eeevil | csharp_: if you have test-env tuits, I'm glancing longingly in your direction ... ;) |
| 15:21 | Dyrcona | I can't promise anything. I'm terribly swamped lately. |
| 15:22 | * csharp_ | bats eyelashes |
| 15:22 | shulabramble | #action eyes wanted on Redis Stream-based HA/LB branch (https://bugs.launchpad.net/opensrf/+bug/2116980) |
| 09:56 | Dyrcona | :) |
| 09:56 | Dyrcona | I'm trying it with PCRE2. |
| 10:01 | Dyrcona | Looking at it, the interface isn't more complicated, it's just different. |
| 10:21 | Dyrcona | Oof... I dropped my change for checking libdbi with my latest change on the test vm. |
| 10:24 | Dyrcona | Yay! Configure works. |
| 10:37 | Dyrcona | Wow! More changes. |
| 10:39 | sandbergja joined #evergreen | |
| 12:27 | Dyrcona | OK. Some mumbo jumbo about the info on the concerto logins page not working. When I changed a patron's password to something that I know what it is, it worked. |
| 12:46 | collum joined #evergreen | |
| 14:04 | Dyrcona | We should stop supporting installation on Debian 10 "Buster." It is EOL since June of 2024. |
| 14:24 | Dyrcona | Tests are failing on Debian trixie. |
| 14:32 | Dyrcona | I think I might add a follow up on the pcre2 commit to log the error from pcre2_match. We can log it, so why not? |
| 14:32 | sandbergja joined #evergreen | |
| 14:40 | Dyrcona | Ugh.... I love it when all I do is reload the database and restart services and the failing tests all suddenly pass. |
| 14:41 | Dyrcona | Who knew that mucking with 1 user's password would break so much? |
| 14:57 | Dyrcona | I love how tests just seem to randomly fail. |
| 15:16 | sandbergja | it would be much nicer if our perl live tests that require a very specific database state could be responsible for setting up that state themselves. Rather than just hoping for the best. |
| 15:19 | sandbergja | it's a bit annoying that for some tests, you can't run them twice in a row; you have to reload the database before each run. Makes it pretty time consuming to see if your changes broke anything haha |
| 16:04 | Dyrcona | Well, it's also annoying when 1 fails on a clean database; you reload it; it passes; reload again; it fails. |
| 16:06 | Dyrcona | I think I had a bunch of test failures on my first run because I had the wrong branch checked out when I built the database. |
| 16:07 | Dyrcona | After that the tests passed 2 out of 3 tries. |
| 16:11 | Dyrcona | I am testing the trixie branch on jammy. |
| 16:34 | Dyrcona | Yeah, first time running the perl live tests after a database reload and a bunch of them fail. I bet after a second reload, they all work. |
| 16:34 | Dyrcona | Well, 2 of them failed: cover uploader and remote patron api. I did do autogen.sh -u, so maybe my apache config is broken? |
| 16:34 | Dyrcona | Everything has to be "just so." |
| 16:35 | Dyrcona | Huh.. nginx not running. |
| 16:39 | Dyrcona | hrm.. Apache was still trying to use port 80.... Guess I didn't restart it properly.... |
| 16:39 | Dyrcona | Too many moving pieces. |
| 16:41 | Dyrcona | Everything has to be done in the correct order. |
| 16:44 | Dyrcona | Yeah, now the Perl live test all pass. The pgtap and static perl tests already passed. |
| 16:46 | Dyrcona | That's enough for today. |
| 17:02 | JBoyer joined #evergreen | |
| 17:06 | mmorgan left #evergreen |
| 14:23 | Dyrcona | csharp_++ I was going to check bullseye and bookworm, too. I confirmed it's available on Ubuntu 25.04. I'm going to check noble, too. |
| 14:23 | csharp_ | so yeah, I think we can assume it's fine to change for all debian-ish targets |
| 14:23 | Dyrcona | Yeah. |
| 14:24 | csharp_ | we can put in a testing note in the bug that we need to actually compile on all current versions |
| 14:24 | Dyrcona | Ok. 2 new bugs: 1. Fix configure check for libdbi. 2. Switch to libpcre2. |
| 14:24 | csharp_ | Dyrcona++ |
| 14:25 | Dyrcona | I pushed a signed-off branch for the OpenSRF changes. |
Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148