Time |
Nick |
Message |
06:33 |
|
dbwells joined #evergreen |
07:34 |
|
rjackson_isl_hom joined #evergreen |
08:17 |
|
mantis1 joined #evergreen |
08:29 |
|
alynn26 joined #evergreen |
08:30 |
|
mmorgan joined #evergreen |
08:39 |
|
rlefaive joined #evergreen |
08:44 |
|
rfrasur joined #evergreen |
08:45 |
|
collum joined #evergreen |
08:59 |
|
Dyrcona joined #evergreen |
09:18 |
csharp |
there's still something out there that's generating a bunch of actor drones all at once, but it will need to wait until after the New Year |
09:18 |
csharp |
and it's *vastly* improved |
09:21 |
Dyrcona |
Funny you should mention that just now. I was about to follow up with rjackson_isl_hom on the discussion of hold lists not being retrieved. |
09:22 |
Dyrcona |
I got an email about X NOT CONNECTED TO THE NETWORK messages from Nagios, and decided not to ignore it. |
09:22 |
Dyrcona |
I see a bunch of messages like this: 2020-12-18 09:18:13 bd2-bh5 open-ils.circ: [ERR :1712:CStoreEditor.pm:139:160830108032690] editor[1|3535] request error open-ils.cstore.direct.action.hold_request.retrieve : [16938052,{"flesh":1,"flesh_fields":{"ahr":["current_copy","usr","notes"]}}] : Exception: OpenSRF::EX::Session 2020-12-18T09:18:13 OpenILS::Utils::CStoreEditor /usr/local/share/perl/5.26.1/OpenILS/Utils/CStoreEditor.p |
09:22 |
Dyrcona |
ion Error: opensrfbh5.public/_bh5_1608301080.712111_3269 IS NOT CONNECTED TO THE NETWORK!!! |
09:24 |
Dyrcona |
What I'm not sure of is, WHO is not connected to the network: the cstore or circ drone. |
09:24 |
csharp |
we should improve those errors |
09:24 |
Dyrcona |
We should improve a lot of things. |
09:24 |
csharp |
yes :-/ |
09:28 |
|
tlittle joined #evergreen |
09:29 |
csharp |
open-ils.actor open-ils.actor.ou_setting.ancestor_default.batch - maybe that |
09:29 |
csharp |
many calls at once |
09:30 |
Dyrcona |
Yeah, I've seen those in the logs, thousands of them from the same client apparently. Often for the same setting. |
09:30 |
Dyrcona |
You're still on 3.4? |
09:30 |
csharp |
yep |
09:33 |
Dyrcona |
https://bugs.launchpad.net/evergreen/+bug/1848550 might help. I haven't actually tried on our 3.2 branch, and we're planning to go to 3.6 in April. |
09:33 |
pinesol |
Launchpad bug 1848550 in Evergreen "Cache settings more aggressively in web client" [Undecided,Fix released] |
09:34 |
csharp |
I saw that the other day and didn't remember whether we had applied it until I read my own comment in my signoff :-) |
09:36 |
Dyrcona |
:) I pulled that out of my history and didn't read it again. |
09:39 |
|
dbwells joined #evergreen |
09:40 |
Dyrcona |
So, I have a question about a translation bug in a po file: bug 1661055. How do we go about fixing it, now? |
09:40 |
pinesol |
Launchpad bug 1661055 in Evergreen "Misspelled word in Spanish tpac po file (motrar should be mostrar)" [Undecided,New] https://launchpad.net/bugs/1661055 |
09:41 |
Dyrcona |
csharp: You were looking for krvmga recently. I found a bug that was still assigned to him yesterday, so I thought I'd go through those bugs and update them. |
09:44 |
|
dbwells_ joined #evergreen |
09:45 |
Dyrcona |
Our poor, neglected KPAC.... |
09:49 |
Dyrcona |
I suppose that I should make sure that we haven't fixed something locally before commenting on the bug, eh? Our customization may have repaired a bug and not been shared with the community. |
09:51 |
Dyrcona |
Hmm... I should also check our 3.6 branch.... |
09:54 |
Dyrcona |
One of these changes makes no sense, but I won't trouble you with details. |
09:58 |
|
sandbergja joined #evergreen |
09:59 |
Dyrcona |
No changes that look relevant, so I don't think this bug is a bug any more. |
10:01 |
|
collum joined #evergreen |
10:04 |
Dyrcona |
Here's another question that likely won't get answered, either. Lp 1406788 is confirmed with 7 people saying they're affected by it. I am not able to reproduce it on 3.2.10 nor on 3.6.1, so do I set it to Invalid or Incomplete? |
10:04 |
pinesol |
Launchpad bug 1406788 in Evergreen "KPAC Login Redirect Issue" [Medium,Confirmed] https://launchpad.net/bugs/1406788 |
10:09 |
Dyrcona |
I'm going with Incomplete since that will keep the bug visible in basic Lp search. |
10:25 |
|
jvwoolf joined #evergreen |
10:59 |
Dyrcona |
Bleh... Things are never as simple as they ought to be. |
11:00 |
|
dbwells joined #evergreen |
11:01 |
mmorgan |
Indeed! Dyrcona++ |
11:08 |
Dyrcona |
I think I need to address this in EGCatLoader somewhere, not the template. |
11:14 |
Dyrcona |
Eh, no. The login form does look like the right place to do this. That means my template code is not working. |
11:18 |
Dyrcona |
Grrr... template-toolkit-- |
11:21 |
Dyrcona |
Well, it's not template toolkit's fault. It's our convoluted code. |
11:21 |
Dyrcona |
I need to do what I'm doing elsewhere. |
11:22 |
Dyrcona |
Maybe I'll just simplify this logic... |
11:23 |
|
stephengwills joined #evergreen |
11:24 |
Dyrcona |
And, my real problem is that I made changes in master and applied them to a custom 3.2 template.....Things are very different.... |
11:24 |
Dyrcona |
So, I'll test on a 3.6.1 VM... |
11:26 |
Dyrcona |
I wonder if bootstrap OPAC will need a similar fix? |
11:30 |
Dyrcona |
So, it must be some customization.... |
11:32 |
Dyrcona |
Grrr......... customization-- |
11:33 |
Dyrcona |
For the record I did not make most of these customizations. I just managed them in git. |
11:35 |
Dyrcona |
And, it looks like something busted in the customization, either from the author's error or a bad conflict resolution. |
11:36 |
Dyrcona |
Now that is fixed, I see more things that need repair. |
11:37 |
Dyrcona |
Yeah, only part of this ends up applied in our custom login form: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=254a92c |
11:38 |
Dyrcona |
Not sure if I should Dyrcona, krvmga, or tspindler, but since the latter two are no longer here, I'll |
11:38 |
Dyrcona |
@blame Dyrcona |
11:38 |
pinesol |
Dyrcona: Dyrcona is why we can never have nice things! |
11:39 |
Dyrcona |
That's a bit harsh, pinesol. |
11:39 |
Dyrcona |
What was it I said about doing things around vacation? |
11:44 |
csharp |
right - I'm trying to coast today as much as possible so my two weeks off is not interrupted :-) |
11:44 |
csharp |
no changes to anything anywhere |
11:45 |
Dyrcona |
Yeah, I 'm not making production changes, but thought I'd work on some development when I discover that our custom template is busted. |
11:46 |
csharp |
busted today, busted when we get back |
11:50 |
Dyrcona |
What makes this more annoying is I have to update 5 branches because I'm in the middle of switching away from using a customization directory. |
11:51 |
Dyrcona |
At leat I can cherry-pick 3 of them, but then I'll rebase two branches. |
11:55 |
Dyrcona |
Oof... I'm missing other changes in 1 of the branches. Guess I'll leave myself a note for when I get back. |
12:05 |
mmorgan |
berick: Wondering if the issues in comments 19 and 20 of bug 1846042 sound like easy-ish fixes. I'm wondering about signing off and pushing those to another bug. |
12:05 |
pinesol |
Launchpad bug 1846042 in Evergreen 3.5 "Angular admin pages need filters" [High,Confirmed] https://launchpad.net/bugs/1846042 |
12:07 |
|
jihpringle joined #evergreen |
12:46 |
|
alynn26_away joined #evergreen |
12:48 |
|
terranm joined #evergreen |
12:52 |
|
collum joined #evergreen |
13:20 |
abowling |
Apologies if I've missed convo on this, but re: bundling-and-chunking, I've seen numerous instances in systems independent of each other yet where the stanza size in ejabberd matters and certain jobs fail without increasing the max size |
13:21 |
abowling |
FWIW, ALL cases involved upgrading EG, OpenSRF, AND Ubuntu to 18.04, so there are a lot of variables there |
13:23 |
abowling |
To wit, it never seemed to be a problem on EOL EG versions AND <=16.04, so I don't exactly know the culprit, as I haven't dug into the message chunking code. However, I can confirm numerous instances of it resulting in failures that were fixed by upping the max_stanza_size in ejabberd.yml |
13:24 |
abowling |
I happily welcome and feedback or suggestions |
13:25 |
abowling |
*any feedback |
13:29 |
csharp |
we have ours at max_stanza_size: 2000000 |
13:29 |
csharp |
(which you may already know :-)), but we're still on 16.04 in prod (as you also already know) |
13:30 |
csharp |
I'd be curious about what sorts of things are resulting in that happening |
13:30 |
abowling |
csharp: yep. that's where I've bumped all my others. I'm operating per https://evergreen-ils.org/documentation/release/OpenSRF/RELEASE_NOTES_2_5_0.html. "With this change, it is no longer necessary to change the max_stanza_size setting for ejabberd when installing OpenSRF." |
13:31 |
csharp |
abowling: bug 1725317 in case you haven't seen it |
13:31 |
pinesol |
Launchpad bug 1725317 in OpenSRF ""XML stanza is too big" still possible with chunking and bundling" [Undecided,New] https://launchpad.net/bugs/1725317 - Assigned to Galen Charlton (gmc) |
13:31 |
abowling |
csharp: I'll give one such example. Let me pull logs. |
13:31 |
abowling |
csharp: that's exactly the error I was fixin' to pull. :) |
13:33 |
abowling |
and that Dyrcona and dbwells have experienced comforts me in that I didn't fall victim to a novice oversight :D |
13:37 |
csharp |
:-) |
13:38 |
abowling |
csharp: fyi, two business cases where frequent are: marc batch edits and (courtesy|overdue) notices |
13:39 |
abowling |
one client has a considerably verbose template for said notices (more than 64KB of text, I'd guess) |
13:42 |
abowling |
*friday afternoon typo. that should have read "not more"; they're definitely *well* short of 32K words |
13:44 |
abowling |
though amassed in aggregate, i'm sure the xml is bigger than that, so it's a moot point |
13:55 |
pinesol |
[evergreen|Garry Collum] lp1903424 Bootstrap opac notification methods not saving - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1ad04e4> |
14:18 |
|
AFloyd__ joined #evergreen |
14:22 |
|
alynn26 joined #evergreen |
14:58 |
csharp |
we've added an org unit today and now all searches are broken |
14:58 |
csharp |
I'm not seeing anything wrong with the unit itself - autogen.sh runs fine and generates a file with the new org within |
14:59 |
csharp |
Can't call method "opac_visible" on an undefined value at /usr/local/share/perl/5.22.1/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm line 1177. |
15:00 |
csharp |
which is from this sub: https://git.evergreen-ils.org/?p=evergreen/pines.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm;h=950a081b63a30b9c0889dbc3ef27fff51150abe7;hb=refs/heads/rel_3_4_1#l1175 |
15:00 |
|
Dyrcona joined #evergreen |
15:00 |
csharp |
it's like it's not seeing an org at all |
15:04 |
Dyrcona |
It's the call before that one that isn't find the org. Are your depths correct on the new org and its parent? |
15:04 |
* Dyrcona |
should have just stayed signed out, but bored. :) |
15:06 |
Dyrcona |
abowling: I still occasionally have issues with max_stanza_size, particularly with autorenewal notices. A few months ago, I bumped the max stanza size again on one our utility server that runs the action triggers. I think I bumped it to 5 or 10MB. |
15:06 |
csharp |
misery loves company |
15:07 |
csharp |
I was happy earlier when I thought I would coast into vacation, but this is going to take up the rest of the day unless I find the problem |
15:07 |
Dyrcona |
Well, I went to my in-laws to shovel snow, came home, and I'm sitting here thinking what can I do now? So, after reading some tech news, I sign in here. |
15:07 |
csharp |
currently I'm wondering if there's something wrong with OrgTree.js |
15:07 |
Dyrcona |
Well, your first mistake was changing something on a Friday. :) |
15:07 |
csharp |
like, is it too big? |
15:08 |
csharp |
yeah, if it were up to me I wouldn't be here - one of my colleagues added an org |
15:08 |
Dyrcona |
Too big for what? A browser to parse? |
15:08 |
csharp |
I'm grasping at straws |
15:08 |
Dyrcona |
I'd double check the depths and parent org units to start. |
15:10 |
Dyrcona |
csharp: That line number is from 3.4, right? |
15:11 |
csharp |
yes, that's right |
15:11 |
csharp |
that's our repo |
15:12 |
csharp |
https://git.evergreen-ils.org/?p=evergreen/pines.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm;h=950a081b63a30b9c0889dbc3ef27fff51150abe7;hb=refs/heads/rel_3_4_1#l1175 |
15:15 |
Dyrcona |
Well, looks like theres code around lines 1461 that makes me suspect your depths are broken. |
15:16 |
Dyrcona |
I'm guessing that $dorgs or $aorgs is coming up undef. |
15:16 |
csharp |
still looking... |
15:18 |
Dyrcona |
Either that or you're dealing with some sort of memcached/cache issue. |
15:18 |
Dyrcona |
auotgen should take care of that, though. |
15:20 |
csharp |
broken depths seems more likely - trying to rule that out now |
15:23 |
Dyrcona |
Yeah. |
15:36 |
|
mantis1 left #evergreen |
15:42 |
csharp |
ok, it's broken on 4 of our six bricks |
15:42 |
csharp |
autogen.sh doesn't appear to help at all |
15:46 |
Dyrcona |
That's odd. |
15:46 |
Dyrcona |
cache? |
15:52 |
mrisher |
hi all! |
15:53 |
JBoyer |
Yikes. Yeah, this sounds similar to things I've seen back before autogen.sh would auto-clear the cached org tree, but I don't think PINES is on a version old enough for that to still be an issue. Busted org depths does sound like a possibility though |
15:53 |
mrisher |
I have a bug which I made a pull request for. Then it was reviewed and signed off on. Then a suggestion for improvement got made, so I improved the work. Now do I keep it tagged pull request, or signed off, or ?? |
15:54 |
mrisher |
not sure how to handle launchpad tagging in this case |
15:54 |
JBoyer |
mrisher, If you think the new commit(s) are good to go as is then it should probably keep pullrequest, but the signedoff tag should probably come off to signal that it's not 100% ready to push upstream as-is. |
15:55 |
mrisher |
ok, I'll remove signedoff from it. thanks. |
15:55 |
JBoyer |
mrisher++ |
15:59 |
terranm |
mrisher++ |
16:02 |
JBoyer |
csharp, any luck tracking down your phantom OU? |
16:04 |
terranm |
He's still working on it. Last day before vacation is always like an action movie where it's a cop's last day before retirement. |
16:05 |
rhamby |
terranm so the serial killer he thought he put away for life has gotten out and has kidnapped his family? |
16:05 |
JBoyer |
Im too old for this (code)! |
16:05 |
rhamby |
I hate it when that happens. |
16:06 |
terranm |
rhamby: and the serial killer's name is 4 Bricks |
16:06 |
rhamby |
that %@$%^ |
16:06 |
jeff |
I misread, thought terranm was the coworker who turns out to be a serial killer. |
16:06 |
terranm |
jeff: shhhhh |
16:06 |
JBoyer |
terranm, I hope it turns out, pass along well wishes and I hope everyone has a good holiday! |
16:07 |
jeff |
terranm: oh, did i say that out loud? |
16:07 |
terranm |
Thx Jason, you too |
16:09 |
csharp |
JBoyer: everything looks fine from the DB end |
16:10 |
csharp |
decided to delete the new org |
16:13 |
csharp |
current theory of mine is that adding the org pushed something beyond a threshold somewhere because the logs are clearing up after deleting |
16:14 |
csharp |
during my troubleshooting, I decided to use Data::Dumper to output $org in this line: https://git.evergreen-ils.org/?p=evergreen/pines.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm;h=950a081b63a30b9c0889dbc3ef27fff51150abe7;hb=refs/heads/rel_3_4_1#l1176 |
16:15 |
csharp |
it appeared to be an array containing every org unit in PINES and I'm wondering if it was too many to process |
16:16 |
Dyrcona |
At that point, it should be only 1 org. If you're getting multiple orgs there, some thing is broken in the code higher up. |
16:17 |
csharp |
yeah, that was my thought too |
16:17 |
csharp |
I'm just trying to get us back to square one and will tackle this after my vacation |
16:18 |
Dyrcona |
Yeahp. |
16:19 |
jeff |
hah! wondered why the org went away. |
16:20 |
jeff |
good luck. :-) |
16:23 |
csharp |
heh - thanks for looking jeff |
16:23 |
csharp |
I'm finally walking away - back on 1/4/21 |
16:24 |
csharp |
everyone have a great holiday! |
16:43 |
jeff |
OpenILS::Application::get_org_tree has a process-local cache of the org tree by locale. I don't think anything clears it other than a fresh process. |
16:52 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2020-12/2020-12-18_16:00:03/test.7.html> |
17:26 |
|
mmorgan left #evergreen |
17:49 |
|
sandbergja joined #evergreen |
18:06 |
jeff |
er, that should be OpenILS::Application::AppUtils::get_org_tree |
22:09 |
|
sandbergja joined #evergreen |