| Time |
Nick |
Message |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 07:41 |
|
rjackson_isl_hom joined #evergreen |
| 08:06 |
|
collum joined #evergreen |
| 08:19 |
|
collum joined #evergreen |
| 08:27 |
|
mantis joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:39 |
|
mmorgan1 joined #evergreen |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:52 |
|
mmorgan2 joined #evergreen |
| 09:01 |
|
collum_ joined #evergreen |
| 09:26 |
|
Dyrcona joined #evergreen |
| 09:29 |
|
alynn26 joined #evergreen |
| 09:29 |
|
jvwoolf joined #evergreen |
| 09:33 |
|
collum joined #evergreen |
| 10:06 |
|
Cocopuff2018 joined #evergreen |
| 10:10 |
mantis |
Got a pretty involved question. We updated to 3.5.4 from 3.1.16 and noticed issues with the EDI from staff. We thought we must have needed to run the crontab but get this error for one of them |
| 10:10 |
mantis |
ERROR: No edi_default account found for provider 260 (Baker & Taylor, Inc. (mnb&tj)). File will not be sent! |
| 10:10 |
mantis |
Can't call method "id" on an undefined value at ./edi_pusher.pl line 163. |
| 10:10 |
mantis |
Any advice would be appreciated |
| 10:22 |
Dyrcona |
mantis: Are you using the new style of EDI accounts with attributes? |
| 10:22 |
Dyrcona |
Also, the edi_pusher.pl is the old style EDI pusher and it needs ruby webrick running, IIRC. |
| 10:25 |
mantis |
We're running the old version |
| 10:26 |
Dyrcona |
Check if webrick is running on the server where the pusher runs: pgrep -af webrick |
| 10:28 |
mantis |
It's running |
| 10:30 |
Dyrcona |
Well, then, I assume that provider needs to be fixed, and I don't know that much about acquisitions. |
| 10:46 |
JBoyer |
mantis, something I thought was odd is that there's a 2-way link in the db for some EDI things. I don't have the details at hand, but something along the lines of an edi_account having a link ot provider, and a provider needing a link to a default edi account or similar. I hope that gives you something to look for at least. |
| 10:52 |
collum |
mantis, we are on 3.4. In the provider definition there is a EDI Default column, which according to the documentation, is the default EDI Account. None of our providers are actually attached to accounts. So something to look forward to. |
| 10:52 |
collum |
https://docs.evergreen-ils.org/eg/docs/latest/installation/edi_setup.html#_configuring_providers |
| 11:25 |
|
rfrasur joined #evergreen |
| 12:03 |
|
sandbergja joined #evergreen |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:14 |
jeffdavis |
gmcharlt_: I pushed an update to your collab branch for bug 1923225 - I'm also happy to sign off on that branch but wasn't sure if I should modify the existing commits by adding my signoff |
| 12:14 |
pinesol |
Launchpad bug 1923225 in Evergreen "ISBN display includes code in traditional catalogue" [Medium,Confirmed] https://launchpad.net/bugs/1923225 |
| 12:21 |
gmcharlt_ |
jeffdavis: Thanks! I'm fine with you force-pushing to the collab branch |
| 12:21 |
gmcharlt_ |
if it doesn't let you, I'll add the signoffs when I review your additions |
| 12:21 |
|
gmcharlt joined #evergreen |
| 12:28 |
Dyrcona |
I don't think you can force push to someone else's collab branch. |
| 12:30 |
jeffdavis |
confirmed - I tried force-pushing and got an error |
| 12:32 |
Dyrcona |
The solution to that is to a) let gmcharlt add your signoff or b) push to a new working branch. |
| 13:17 |
|
Cocopuff2018 joined #evergreen |
| 13:45 |
Dyrcona |
So, we have a cstore that seems to suffer from a memory leak. Every couple of days we get an email from nagios that memory use on the server that runs the fine generator is low. I go check and it's a cstore drone, usually doing nothing at the time, that's using 5+GB of RAM. |
| 13:46 |
Dyrcona |
I've adjusted the max_requests for this server down to 100 to see if that makes a difference. |
| 13:48 |
|
jvwoolf joined #evergreen |
| 13:49 |
Dyrcona |
The only code change between 3.2.10 and 3.5.3 that looks like it could have an effect is the fix for pcrud null authtokens. |
| 13:53 |
gmcharlt |
can you figure out if the memory ballooning tied to a specific request? our experience tends to show that sort of thing happening if there's a bug leading to a client requesting "gimme all bib records" or the like |
| 13:54 |
Dyrcona |
I believe it is associated with the fine generator, because that is about the only thing that this server runs that uses cstore. |
| 13:55 |
Dyrcona |
I should check differences in the fine generator and open-ils.circ. |
| 13:56 |
Dyrcona |
And... the fine generator hasn't changed since 2011. |
| 13:58 |
|
sandbergja joined #evergreen |
| 14:01 |
Dyrcona |
No smoking gun. |
| 14:03 |
Dyrcona |
Ah... The fine generator is using parallel 1. That might be it, since 1 drone is doing everything. I'm going to look at the git log in my branch to see if I can figure out when/why that changed. I think we used to use a parallel of 3 or 6. |
| 14:08 |
Dyrcona |
I can't find any evidence of any changes to the fine generator parallel setting in my git logs, at least for the current and previous branches. I may have adjusted it manually, and if so, that file is gone. |
| 14:16 |
Dyrcona |
I have this notion that there was a reason we deliberately when to 1 for the fine generator, but I can't find anything about it in the git history. |
| 14:16 |
Dyrcona |
I could be mistaken. I have plenty of evidence of making adjustments to the other settings over time. |
| 14:21 |
|
devted_ joined #evergreen |
| 14:23 |
|
csharp_ joined #evergreen |
| 14:30 |
|
csharp joined #evergreen |
| 14:30 |
Dyrcona |
So, I've set the fine generator parallel to 3 to see what happens. |
| 14:30 |
csharp |
Dyrcona: yeah, I've seen that exact issue before - parallel should help |
| 14:31 |
Dyrcona |
csharp: Did you reduce max_requests or leave it at 1000? |
| 14:41 |
csharp |
er... |
| 14:42 |
csharp |
we have max_requests at 1000 for open-ils.actor |
| 14:47 |
Dyrcona |
It's open-ils.cstore, but OK. |
| 14:47 |
Dyrcona |
I'm adjusting it just for this server. |
| 14:48 |
Dyrcona |
If things look good after a couple of days with parallel, I'll go back to 1000. |
| 14:55 |
* Dyrcona |
waits for the fine generator to run at 3:00 pm. |
| 14:55 |
jeffdavis |
csharp: do you run into memory issues with max_requests set that high? |
| 14:55 |
Dyrcona |
jeffdavis: It's the default for most services. |
| 14:57 |
jeffdavis |
right, I'm thinking of max_children, sorry |
| 15:05 |
Dyrcona |
So, while the fine generator is running, it's mostly storage drones doing the work. |
| 15:15 |
Dyrcona |
I think the max requests 100 is "working." All of the running cstore drones have high process ids. I'll leave things like this for a few days to see what happens. |
| 15:15 |
Dyrcona |
They also have low memory use. |
| 15:35 |
|
mantis left #evergreen |
| 15:59 |
|
sandbergja joined #evergreen |
| 16:27 |
|
jamesrf joined #evergreen |
| 16:55 |
|
bshum joined #evergreen |
| 17:23 |
|
mmorgan left #evergreen |
| 17:24 |
|
jeff_ joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2021-04/2021-04-27_16:00:05/test.29.html> |
| 19:39 |
|
sandbergja joined #evergreen |
| 20:53 |
|
dbwells_ joined #evergreen |
| 22:18 |
|
sandbergja joined #evergreen |
| 23:01 |
|
sandbergja joined #evergreen |
