| Time |
Nick |
Message |
| 01:04 |
|
dbwells_ joined #evergreen |
| 01:05 |
|
remingtron_ joined #evergreen |
| 01:14 |
|
dbwells__ joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 07:02 |
|
JBoyer joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 08:06 |
|
Dyrcona joined #evergreen |
| 08:07 |
|
Jillianne joined #evergreen |
| 08:14 |
|
mdriscoll joined #evergreen |
| 08:33 |
|
_bott_ joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:57 |
|
kmlussier joined #evergreen |
| 09:01 |
|
_adb joined #evergreen |
| 09:07 |
|
rlefaive_ joined #evergreen |
| 09:09 |
JBoyer |
mdriscoll, kmlussier, csharp: I noticed the talk about upgrade script 1057 in the logs, the real issue is the trigger that maintains the 901c subfield. It's causing every record in your entire db, deleted or not, to be parsed by the MARC::XML perl module and the 901 rebuilt. |
| 09:10 |
JBoyer |
If that winds up changing the marc field it will be reingested, but otherwise it's still just overly slow for no reason. For that script on my testing server I disabled all of the triggers and ignored the deleted records to get it down to somewhere between 30 and 90 mins. |
| 09:10 |
csharp |
JBoyer: oh - awesome |
| 09:11 |
mdriscoll |
JBoyer: I'll try that, thanks! |
| 09:12 |
kmlussier |
JBoyer++ |
| 09:12 |
JBoyer |
I'd like to see a lot of those triggers consolidated and gated behind an IF OLD.marc != NEW.marc... especially the 901c maintainer. I just haven't bugged or bothered. :/ |
| 09:13 |
csharp |
sounds like a worthwhile approach |
| 09:16 |
|
yboston joined #evergreen |
| 09:20 |
|
StephenGWills joined #evergreen |
| 09:20 |
miker |
we recently had a similar need (disable all triggers without a bunch of interruption) and gmcharlt pointed out "SET session_replication_role TO 'replica';" -> https://stackoverflow.com/questions/3942258/how-do-i-temporarily-disable-triggers-in-postgresql for a non-normative example |
| 09:21 |
miker |
better than directly disabling triggers, because no exclusive table lock is required |
| 09:24 |
Dyrcona |
JBoyer++ |
| 09:25 |
Dyrcona |
I skipped adding the 901$c at one point because slow. |
| 09:25 |
JBoyer |
Well, if you're running an upgrade script I imagine it's not too difficult to get an exclusive lock. ;) I'll read up on that though. I will say without knowing any of the details, saying "You're a replica now!" makes me nervous. |
| 09:25 |
Dyrcona |
Yeah, me, too. |
| 09:26 |
Dyrcona |
I wrote something as an experiment to replace part of an upgrade script that did 1 record per transaction with an exclusive lock on each. It was still really slow. |
| 09:27 |
Dyrcona |
I forget exactly what it did and I may not have the code any more. |
| 09:27 |
Dyrcona |
Some of the recent upgrades have been doing a lot in the database. |
| 09:28 |
Dyrcona |
Did the 901$c come in 2.10, or is it more recent than that? |
| 09:28 |
Dyrcona |
I seem to recall saying in a meeting that we'd skip it during the upgrade because it's slow and we weren't going to use it right away. |
| 09:30 |
gmcharlt |
901$s? 2.11 |
| 09:30 |
Dyrcona |
Ah, yeah, I was thinking of 901$s... :) |
| 09:31 |
Dyrcona |
We're skipping the update from the upgrade script. |
| 09:32 |
Dyrcona |
gmcharlt++ |
| 09:32 |
Dyrcona |
I don't think I have to worry 1057 just yet. ;) |
| 09:33 |
* Dyrcona |
goes back to working on a purge....the patrons must be cleansed! :) |
| 09:37 |
|
terran joined #evergreen |
| 09:37 |
gmcharlt |
select actor.wash_rinse_repeat()... |
| 09:38 |
Dyrcona |
gmcharlt: That can lead to an endless loop, don't for the escape condition: if desired.... :) |
| 09:39 |
gmcharlt |
... Signed-off-by: Jane.Smith shampoo-manufacturer.com... |
| 09:40 |
Dyrcona |
See I have a bad joke about that: Did you hear about the programmer who died in the shower? He got stuck in lather, rinse, repeat. |
| 09:42 |
|
jvwoolf joined #evergreen |
| 09:43 |
csharp |
Dyrcona++ |
| 09:47 |
|
bos20k joined #evergreen |
| 10:11 |
berick |
do we need to get some trigger disabling magic into the upgrade scripts? |
| 10:13 |
jeff |
well, it would defeat the purpose of some of them... :-) |
| 10:17 |
berick |
i'll start over, are there time-consuming, unneeded triggers we can temporarily disable in the 3.0 upgrade? |
| 10:18 |
berick |
a la JBoyer's solution |
| 10:19 |
Dyrcona |
Unless it was changed again, maintain901c is probably not necessary during an upgrade, but I haven't looked at this particular script. |
| 10:21 |
JBoyer |
It would make sense in that specific script but I don't recall any other issues like that. |
| 10:21 |
Dyrcona |
It would make sense to disable it, you mean? |
| 10:21 |
* Dyrcona |
is being literal. :) |
| 10:22 |
JBoyer |
Yes. The UPDATE in question is for something that has nothing to do with the marc. |
| 10:22 |
JBoyer |
Yes it makes sense to disable them. :P |
| 10:23 |
Dyrcona |
heh. |
| 10:24 |
* Dyrcona |
was just making sure... "Kid, we don't want any hangings." |
| 10:24 |
|
dwgreen joined #evergreen |
| 10:24 |
mdriscoll |
I am running 1057 with b_maintain_901 dropped, also checking for deleted is false in the biblio.record_entry update. I'll see how long it takes on 2m bibs. |
| 10:25 |
kmlussier |
mdriscoll: Good luck! |
| 10:26 |
berick |
mdriscoll++ |
| 10:26 |
mdriscoll |
Could the update in 1075 be run in parallel? I have 16 cores and 15 have nothing to do. |
| 10:28 |
mdriscoll |
s/1075/1057/g |
| 10:34 |
Dyrcona |
Seems to me it would make sense to modify the triggers so that maintain_901 and maintain_control_numbers are only called if the MARC is changed. |
| 10:39 |
Dyrcona |
mdriscoll: You could try doing it in parallel to see. I think it could be. |
| 10:52 |
* kmlussier |
agrees with berick, et al. on disabling the trigger for the upgrade. |
| 10:56 |
miker |
there are no triggers that need to fire during that particular script. I'm still in favor of wrapping the relevant guts of of 1057 in set session_replication_role replica/origin ... pg naming decisions aside, all that does is say "don't fire triggers / do fire triggers" |
| 10:57 |
Dyrcona |
Well, on an unrelated topic I have one for gmcharlt mainly. |
| 10:57 |
Dyrcona |
krvmga and I were talking at lunch yesterday and the thought occurred that maybe OpenSRF 2.6.0, which will likely be required for Evergreen 3.0, should be numbered OpenSRF 3.0. |
| 10:58 |
gmcharlt |
well, that's a Stretch |
| 10:58 |
gmcharlt |
(sorry, I couldn't resist) |
| 10:58 |
Dyrcona |
Assuming that Lp 1708048 goes in. |
| 10:58 |
pinesol_green |
Launchpad bug 1708048 in OpenSRF "Add support for Debian 9 Stretch" [Undecided,New] https://launchpad.net/bugs/1708048 |
| 10:58 |
Dyrcona |
Heh. |
| 10:58 |
JBoyer |
miker, given the reports of "that didn't work for me" in that stackoverflow question I'd prefer that a modified script explicitly disable the known Evergreen triggers and then re-enable them at the end. For one thing, disabling all triggers indiscriminately will cause *some problems* with Slony replication. |
| 10:58 |
JBoyer |
gmcharlt++ |
| 10:59 |
Dyrcona |
I think the numbering could be justified since the library names change, leading to a potentially not backward compatible situation. |
| 10:59 |
gmcharlt |
seriously, I've no strong feelings one way or the other regarding calling it OpenSRF 3.0 |
| 10:59 |
gmcharlt |
and am happy to run with whatever the general consensus ends up being |
| 10:59 |
* gmcharlt |
goes *poof* for a brief meeting |
| 11:00 |
bshum |
OpenSRF 3.0 sounds fun. +1 |
| 11:01 |
JBoyer |
and mdriscoll: if you left the maintain_control_numbers trigger enabled, it's doing essentially the same thing as maintain_901, meaning it will only take half as long as letting both run, but it will be a lot faster if you disable all of the triggers for the duration of that script. |
| 11:01 |
miker |
meh, WORKSFORME is psql test on 9.4. the complaints seem to be about pgadmin. but the script is editable, so... to each site, their own |
| 11:02 |
Dyrcona |
mdriscoll: You're using Pg 9.4, right? |
| 11:02 |
mdriscoll |
JBoyer: ok will do. I was trying to disable as little as possible to see how long it would take. |
| 11:03 |
mdriscoll |
Dyrcona: yes Pg 9.4. |
| 11:11 |
csharp |
berick: results from your debugging lines from yesterday: https://pastebin.com/YNVpFSMM thanks to tlittle for the data |
| 11:12 |
* csharp |
found <head><style type="text/css">* {}</style> to be very interesting :-) |
| 11:12 |
berick |
csharp: well la-dee-da, that's fun |
| 11:14 |
Dyrcona |
Wouldn't that disable all inherited styles? |
| 11:14 |
berick |
no idea what would be adding that, though. |
| 11:14 |
Dyrcona |
But, IIRC, I recall csharp showing an OpenSRF call that had * {} in a bad place. |
| 11:15 |
csharp |
yep |
| 11:15 |
* berick |
finally looks at the paste |
| 11:15 |
berick |
oh, whole bunch of stuff |
| 11:16 |
berick |
grepping for 'shadow-root' in EG returns nothing |
| 11:16 |
Dyrcona |
It's added to the acq upload key, it looks like. |
| 11:17 |
csharp |
https://www.w3.org/TR/shadow-dom/ |
| 11:18 |
csharp |
could this be a chrome add-on wreaking havoc? |
| 11:18 |
berick |
maybe? |
| 11:20 |
Dyrcona |
And, it's experimental... |
| 11:20 |
Dyrcona |
But, I guess it's all experimental on duh webs. |
| 11:22 |
berick |
from a stackoverflow comment, "These come up in things like iframes as well, where you have a separate DOM tree nested inside of another." |
| 11:22 |
berick |
https://stackoverflow.com/questions/34119639/what-is-shadow-root |
| 11:22 |
berick |
maybe native chrome is adding it |
| 11:23 |
berick |
(sometimes) |
| 11:23 |
berick |
... and the browser client is loading vandelay in a iframe |
| 11:23 |
berick |
/a/an/ |
| 11:25 |
Dyrcona |
Now, the tools are fighting us, instead of the other way around. |
| 11:29 |
|
abowling joined #evergreen |
| 11:29 |
berick |
if necessary, we could make vandelay return HTML. <span id='look-over-here'>$key</span> |
| 11:29 |
berick |
still troubling, though |
| 11:37 |
miker |
hrm... content-type header? |
| 11:37 |
* miker |
wonders if it's text/html when it maybe should be text/plain |
| 11:38 |
* dbwells |
was thinking along the same lines, but hasn't followed along closely at all |
| 11:39 |
JBoyer |
Seems a reasonable assumption |
| 11:41 |
berick |
it's text/plain |
| 11:41 |
berick |
$r->content_type('text/plain; charset=utf-8'); |
| 11:43 |
Dyrcona |
charp: Does it happen in Chromium? |
| 11:44 |
dbwells |
berick: maybe ignorant, but any particular reason we are using handleAs "html" instead of just "text"? |
| 11:44 |
berick |
dbwells: no, that's a good question. i don't know the answer |
| 11:45 |
berick |
seems like a good thing to experiment with, though |
| 11:47 |
pastebot |
"dbwells" at 64.57.241.14 pasted "csharp, just spitballing" (15 lines) at http://paste.evergreen-ils.org/812 |
| 11:47 |
berick |
+1 |
| 11:47 |
berick |
and maybe throw in a console.log(data) |
| 11:48 |
dbwells |
csharp: oops, sorry, got cutoff. You know what it means :) |
| 11:48 |
* gmcharlt |
tosses a spare semicolon into the channel |
| 11:49 |
pastebot |
"dbwells" at 64.57.241.14 pasted "csharp, second try" (15 lines) at http://paste.evergreen-ils.org/813 |
| 11:50 |
csharp |
well, in the meantime, we have determined that a chrome addon was creating the extra characters |
| 11:51 |
csharp |
https://chrome.google.com/webstore/detail/font-changer-with-google/jgjhhoglgjdklldfgoffdiaceffijeke?hl=en |
| 11:51 |
berick |
parallel-ingest-bugfixes.pl |
| 11:54 |
Dyrcona |
Probably wrong window, but that looks interesting just the same. :) |
| 11:55 |
berick |
right window, wrong level of funniness |
| 11:55 |
Dyrcona |
heh |
| 12:01 |
csharp |
dbwells: I applied it and it resulted in an "undefined" key :-/ |
| 12:02 |
csharp |
that's with the add-on enabled, FYI |
| 12:02 |
csharp |
too many variables here |
| 12:03 |
dbwells |
csharp: was afraid of that. Dojo apparently has a silly restriction of requiring "text" be returned in an HTML document textarea. :/ |
| 12:04 |
csharp |
ACQ UPLOAD KEY DOM: undefined |
| 12:04 |
csharp |
without the addon^^ |
| 12:05 |
* csharp |
steps afk for a bit |
| 12:17 |
|
jihpringle joined #evergreen |
| 12:18 |
|
krvmga joined #evergreen |
| 12:19 |
|
khuckins joined #evergreen |
| 12:20 |
dbwells |
csharp: when you get back... Are you sure the key was undefined? berick's previous debug lines won't really work anymore, so as he suggested, something like a simple console.log(data) would give a rough idea where we stand. |
| 12:22 |
dbwells |
csharp: otherwise, I can suggest changes needed to do the textarea wrapping, but that seems pretty ugly overall. |
| 12:53 |
|
khuckins_ joined #evergreen |
| 13:08 |
berick |
dbwells: tried your patch. dojo is definitely intervening. just calling console.log(data) preduces an error. (cannot read property 'value' of undefined). |
| 13:08 |
berick |
i guess it has its own stringify and assumes a textarea, like you said |
| 13:16 |
jeffdavis |
CALL: open-ils.cstore open-ils.cstore.direct.action.all_circulation_slim.search.atomic {"target_copy":10732027},{"flesh_fields":{"aacs":["workstation","checkin_workstation","duration_rule","max_fine_rule","recurring_fine_rule"]},"limit":1,"flesh":1,"order_by":{"aacs":"xact_start desc"}} |
| 13:16 |
jeffdavis |
open-ils.cstore ERROR No "datatype" attribute for field "target_copy" |
| 13:17 |
jeffdavis |
That latter error is from oils_sql.c, anyone know what it means? |
| 13:17 |
jeffdavis |
I'm seeing a lot of those. |
| 13:18 |
gmcharlt |
this may be of interest to folks regarding Firefox Screenshots: https://lists.katipo.co.nz/pipermail/koha/2017-September/048969.html |
| 13:18 |
Dyrcona |
jeffdavis: Check your fm_ILD.xml. It may be out of date or messed up. |
| 13:19 |
gmcharlt |
the bit of JavaScript mentioned on the Koha wiki page can be plopped into webstaff's base_js.tt2 and just work |
| 13:20 |
jeffdavis |
thx Dyrcona |
| 13:20 |
Dyrcona |
gmcharlt: That "feature" apparently hasn't made it into Firefox 55 on Linux, or it is not on by default. |
| 13:21 |
gmcharlt |
Dyrcona: yeah, they seem to be doing A/B testing during the release, so I think it is on for some |
| 13:23 |
kmlussier |
gmcharlt++ |
| 13:23 |
gmcharlt |
and for those institutions that manage their deployments of Firefox to library staff, there's this - https://support.mozilla.org/en-US/questions/1168009 |
| 13:48 |
* csharp |
switches gears back to other acq issue where A/T is crapping out on undefined values |
| 13:49 |
csharp |
example from last week: https://pastebin.com/raw/CHpP91fn - logging $context within _object_by_path in Event.pm |
| 13:49 |
csharp |
not sure what's causing the blank lines |
| 13:50 |
csharp |
'Can't call method "class_name" on an undefined value at /usr/local/share/perl/5.18.2/OpenILS/Application/Trigger/Event.pm line 594.' is the error that it dies on |
| 13:50 |
csharp |
line 594 is my $fhint = OpenILS::Application->publish_fieldmapper->{$context->class_name}{links}{$step}{class}; |
| 13:52 |
gsams |
csharp++ #for giving me most of the knowledge and tools necessary to properly train folks on reports |
| 13:53 |
Dyrcona |
csharp: $context is undefined. So, where does $context come from and that's likely the bug. |
| 13:53 |
csharp |
gsams: aww - thanks! |
| 13:54 |
Dyrcona |
csharp: Is this with OpenSRF 2.5? |
| 13:54 |
* Dyrcona |
saw similar weird errors until applying the chunking fix. |
| 13:55 |
csharp |
Dyrcona: yes |
| 13:55 |
csharp |
chunking fix? |
| 13:56 |
Dyrcona |
csharp bug 1709710 |
| 13:56 |
pinesol_green |
Launchpad bug 1709710 in Evergreen "Default ejabberd max_stanza_size can be exceeded when chunking (MARC)XML-heavy responses" [Undecided,Confirmed] https://launchpad.net/bugs/1709710 |
| 13:57 |
Dyrcona |
You grep the osrfsys or error logs for stanza to see if that might be the issue. |
| 13:57 |
Dyrcona |
But, I opened a different bug about search being broken. |
| 13:57 |
csharp |
oooh |
| 13:57 |
csharp |
that may fix the z39.50 issue we're seeing too |
| 13:57 |
|
rlefaive joined #evergreen |
| 13:57 |
Dyrcona |
I recall see several undefined value errors where there's no explanation for the value being undefined otherwise. |
| 13:58 |
dbwells |
csharp: about to head to a 2:00pm meeting, but if you want to dig your acq hole a little deeper, I have another paste to add to the first, one sec |
| 13:59 |
pastebot |
"dbwells" at 64.57.241.14 pasted "csharp: wrap textarea for dojo "text"" (12 lines) at http://paste.evergreen-ils.org/814 |
| 13:59 |
csharp |
dbwells: thanks - will look |
| 13:59 |
csharp |
Dyrcona++ # thanks for the pointer! |
| 13:59 |
* dbwells |
should probably just figure out how to produce the problem locally |
| 14:00 |
|
khuckins__ joined #evergreen |
| 14:02 |
berick |
dbwells: csharp: beware that Vandelay.pm change might break Open-ILS/web/js/ui/default/vandelay/vandelay.js |
| 14:10 |
csharp |
berick: noted, thanks |
| 14:27 |
Dyrcona |
Hmm. Looks like OpenSRF 2.5.1 was released but the repo was not tagged. |
| 14:33 |
Dyrcona |
I suppose I could tag it.... |
| 14:34 |
jeffdavis |
So, we upgraded OpenSRF to the latest rel_2_5 last night and saw a bunch of errors this AM at various places in the XUL client (e.g. workstation registration) that looked like JSON parsing errors. Doing `git reset --hard a9cd124` on the opensrf rel_2_5 branch and reinstalling seems to have made the errors go away. |
| 14:34 |
pinesol_green |
jeffdavis: [opensrf|Bill Erickson] LP#1697029 Log and exit on write to dead child - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a9cd124> |
| 14:34 |
jeffdavis |
That reset gets rid of the fixes for bug 1709710 (plus a few other things). |
| 14:34 |
pinesol_green |
Launchpad bug 1709710 in Evergreen "Default ejabberd max_stanza_size can be exceeded when chunking (MARC)XML-heavy responses" [Undecided,Confirmed] https://launchpad.net/bugs/1709710 |
| 14:35 |
jeffdavis |
I'll test more when things are calmer here. |
| 14:38 |
Dyrcona |
jeffdavis: I may be able to set up a test of OpenSRF rel_2_5 and Evergreen 2.12. (I assume you have the issue with 2.12.) |
| 14:38 |
Dyrcona |
I only tested the changes with master OpenSRF and master Evergreen. |
| 14:38 |
jeffdavis |
yeah, we're on 2.12.1 with some backports |
| 14:39 |
Dyrcona |
Well, I'd recommend going all the way to 2.12.5, but I know that can be difficult (not technically, but politically). |
| 14:40 |
Dyrcona |
Since I was just working on documentation to prepare for our upgrade next month, maybe I should put that aside and build the test vm now..... |
| 14:40 |
Dyrcona |
jeffdavis: You say had trouble with workstation registration. Anything else that I could try to reproduce? |
| 14:41 |
jihpringle |
Drycona: stat cats for one of our sites disappeared in the copy editor as well |
| 14:42 |
Dyrcona |
jihpringle: Thanks. |
| 14:44 |
jeffdavis |
We also have a fairly large max_stanza_size to begin with. |
| 14:47 |
bshum |
Hmm |
| 14:47 |
bshum |
I'm not getting any XUL errors with the latest master/opensrf as of two nights ago (which includes the chunking stuff) |
| 14:49 |
bshum |
Registered a new workstation, new patron, searched okay |
| 14:49 |
mmorgan |
jeffdavis: We're running a training server with Evergreen 2.12.4 and OpenSRF 2.5.1 and aren't seeing xul errors. |
| 14:51 |
* Dyrcona |
holds off on tagging osrf_rel_2_5_1, just the same. |
| 14:53 |
Dyrcona |
jeffdavis: Did you figure out your cstore issue from earlier? It could be related. |
| 14:53 |
Dyrcona |
OK. I'm going to do just an update of OpenSRF, without rebuilding Evergreen. |
| 14:54 |
Dyrcona |
bshum and I are chatting in private, and he wonders if that might be the problem. |
| 14:57 |
csharp |
so is OpenSRF 2.5.1 basically the chunking fix? |
| 14:57 |
bshum |
There was something else in there too I thought |
| 14:57 |
jeffdavis |
I updated EG as well last night after the OpenSRF update. One of the EG updates was updating some stuff including the addition of aacs (to support some web client fixes that we need). I haven't seen that 'No "datatype" attribute for field "target_copy"' error since the OpenSRF rollback. |
| 14:57 |
csharp |
cuz we'll just re-deb-ify it and install 2.5.1 (since we have to rebuild everything anyway) |
| 14:57 |
jeffdavis |
There's also a9cd124 and maybe a few other things? |
| 14:57 |
pinesol_green |
jeffdavis: [opensrf|Bill Erickson] LP#1697029 Log and exit on write to dead child - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a9cd124> |
| 14:58 |
csharp |
jeffdavis: cool - I manually applied that over the weekend |
| 14:59 |
* csharp |
has to jet - checking back in later |
| 15:00 |
Dyrcona |
jeffdavis: Do you normally install from git? |
| 15:00 |
jeffdavis |
yes |
| 15:00 |
Dyrcona |
And, did you git clean -x -f -d before hand? |
| 15:00 |
Dyrcona |
I'd like to redo your steps if possible. |
| 15:00 |
jeffdavis |
wiped out the local copies of the opensrf and evergreen repos entirely :) |
| 15:01 |
Dyrcona |
All right. I'll git clean and reconfigure.... |
| 15:01 |
Dyrcona |
You rebuilt Evergreen, too? |
| 15:02 |
jeffdavis |
yeah |
| 15:02 |
jeffdavis |
I can email you the scripts I used it you like |
| 15:02 |
jeffdavis |
*if |
| 15:02 |
Dyrcona |
That's OK. I think I know what I need to do. |
| 15:03 |
Dyrcona |
I'm going to test upgrading OpenSRF but leaving Evergreen untouched, first. |
| 15:05 |
abneiman |
anyone else getting timeout errors from docs.evergreenils.org? the main page loads but links into the docs themselves are timing out for me. |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:08 |
berick |
abneiman: site doesn't load at all for me |
| 15:09 |
abneiman |
I guess I just have the main paged cached... thanks for checking |
| 15:20 |
Dyrcona |
I was able to add a copy using my account at my working ou. |
| 15:20 |
Dyrcona |
jeffdavis: Have you run autogen.sh lately? |
| 15:24 |
Dyrcona |
I did get an error trying to register a workstation. |
| 15:25 |
jeffdavis |
The WS reg error we saw was something like this: {"payload":[],"debug":"osrfMethodException : *** Call to [open-ils.actor.org_tree.descendants.retrieve] failed for session [1505413938.808759.150541393818259], thread trace [1]:\n':' expected, at character offset 31326 (before \"702\",null,\"1513\",nul...\") at /usr/local/share/perl/5.18.2/OpenSRF/Utils/JSON.pm line 109.\n\n","status":500} |
| 15:25 |
jeffdavis |
And yeah, I did run autogen - several times, with fingers crossed :) |
| 15:26 |
Dyrcona |
Yeah, that is similar to what I'm seeing. |
| 15:28 |
Dyrcona |
Then it says Type Error: branch is undefined |
| 15:30 |
Dyrcona |
I'll open a LP bug with the error message and logs. |
| 15:35 |
Dyrcona |
Interestingly, I got this when shutting down services: |
| 15:35 |
Dyrcona |
timed out waiting on open-ils.cstore pid=11334 to die |
| 15:36 |
Dyrcona |
It's not terribly unusual, but it seems like too much of a coincidence. |
| 15:36 |
Dyrcona |
I'm going to reinstall Evergreen to see if that makes a difference before opening the bug. Tomorrow I'll try with a fresh installation on a fresh vm. |
| 15:43 |
Dyrcona |
So, after that I get a different error message. I'll save those logs, too. |
| 15:52 |
Dyrcona |
Register workstation seems to work in the web staff client, btw. |
| 15:54 |
jihpringle |
Drycona: we could register workstations in the web client too |
| 15:55 |
Dyrcona |
I'll open a bug for now. I want to test with a clean installation tomorrow. |
| 16:02 |
* bshum |
grumbles as he makes himself a new Mac client |
| 16:10 |
Dyrcona |
jeffdavis jihpringle: bug 1717350 |
| 16:10 |
pinesol_green |
Launchpad bug 1717350 in Evergreen "Upgrading to OpenSRF 2.5.1 appears to break XUL 2.12.5" [Undecided,New] https://launchpad.net/bugs/1717350 |
| 16:10 |
Dyrcona |
In case you have something to add or want to confirm/hit the "Me, too!" button. ;) |
| 16:11 |
jeffdavis |
Dyrcona++ |
| 16:11 |
jeffdavis |
just got myself a fresh VM, will try to reproduce from scratch this afternoon |
| 16:16 |
berick |
jeffdavis: mind trying in srfsh? |
| 16:16 |
berick |
srfsh# request open-ils.actor open-ils.actor.org_tree.descendants.retrieve 1, 0 |
| 16:17 |
jeffdavis |
Status: *** Call to [open-ils.actor.org_tree.descendants.retrieve] failed for session [1505420261.542880.150542026112413], thread trace [1]: |
| 16:18 |
jeffdavis |
':' expected, at character offset 31326 (before "702",null,"1513",nul...") at /usr/local/share/perl/5.18.2/OpenSRF/Utils/JSON.pm line 109. |
| 16:18 |
jeffdavis |
berick: ^ that's what I get on a server with the latest (non-rolled-back) 2.5.1 |
| 16:18 |
berick |
thanks |
| 16:18 |
berick |
how about: request open-ils.storage open-ils.storage.actor.org_unit.descendants.atomic 1, 0 |
| 16:19 |
jeffdavis |
Received Exception: |
| 16:19 |
jeffdavis |
Name: osrfResultPartialComplete |
| 16:19 |
jeffdavis |
Status: OK |
| 16:19 |
jeffdavis |
Status: 200 |
| 16:20 |
jeffdavis |
followed by the usua "Request Completed Successfully" + request time |
| 16:20 |
jeffdavis |
*usual |
| 16:20 |
jeffdavis |
I need to step away for a bit, happy to try more stuff later on |
| 16:20 |
berick |
huh |
| 16:20 |
berick |
thanks |
| 16:21 |
berick |
just trying to boil it down to the simplest possible test case |
| 16:23 |
Dyrcona |
berick: FWIW the first request above gives the same message in the lp bug. |
| 16:25 |
Dyrcona |
And I get the osrfResultPartialComplete exception for the second, so same as jeffdavis, more or less. |
| 16:26 |
* Dyrcona |
calls it a day. |
| 16:27 |
|
khuckins_ joined #evergreen |
| 16:37 |
|
mmorgan joined #evergreen |
| 16:39 |
mdriscoll |
Just to follow-up on the time it takes to run the 1057 upgrade script, I dropped all the bib triggers and that script ran in 15 minutes on 2 million not deleted bibs. |
| 16:41 |
mdriscoll |
Actually the copy update in 1057 took an hour on 3 million copies plus the 15 minutes for the bib update. |
| 16:46 |
miker |
@later Dyrcona does building a new staff client after installing opensrf 2.5.1 fix the xul SC? The problem is almost certainly the in-client copy of the opensrf js lib, which needs to be tought about partial responses. |
| 16:46 |
pinesol_green |
miker: We're going to need a bigger boat. |
| 16:46 |
miker |
er, I'll try that again |
| 16:46 |
miker |
@later tell Dyrcona does building a new staff client after installing opensrf 2.5.1 fix the xul SC? The problem is almost certainly the in-client copy of the opensrf js lib, which needs to be tought about partial responses. |
| 16:46 |
pinesol_green |
miker: The operation succeeded. |
| 16:47 |
berick |
miker: hm, but it's reproducable via srfsh |
| 16:47 |
berick |
(examples above) |
| 16:47 |
berick |
w/ simple queries |
| 16:48 |
gmcharlt |
berick: yeah, I was just about to reproduce it by expanding aou |
| 16:49 |
bshum |
New staff client, hmm... |
| 16:49 |
berick |
i tried installing rel_2_12 on top of osrf master and cannot reproduce, fwiw |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
khuckins__ joined #evergreen |
| 17:05 |
miker |
berick: can't reproduce in srfsh, you mean? |
| 17:06 |
berick |
miker: i couldn't reproduce locally in srfsh or xul |
| 17:06 |
miker |
ok, cool |
| 17:06 |
|
mmorgan left #evergreen |
| 17:09 |
gmcharlt |
ooh, I think I see what the problem is |
| 17:09 |
gmcharlt |
one moment |
| 17:10 |
dbwells |
Just poking through the few commits, but the use of substr seems concerning here: http://git.evergreen-ils.org/?p=OpenSRF.git;a=commitdiff;h=be2b2645f7da0907366eb0c99b5d6c231c366b30 |
| 17:10 |
pinesol_green |
dbwells: [opensrf|Bill Erickson] LP#1709710 Count Perl chunk/bundle sizes in bytes - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=be2b264> |
| 17:11 |
dbwells |
That is, the chunks won't be the right size in bytes, no? |
| 17:11 |
gmcharlt |
OK, an explanation and fix of the problem: https://lumen.esilibrary.com/p/9kev0U29.html |
| 17:13 |
gmcharlt |
turns out that substr($foo, 15603.8771652997, 15603.8771652997) can have ... interesting results |
| 17:28 |
gmcharlt |
and pull requested https://bugs.launchpad.net/opensrf/+bug/1717350 |
| 17:28 |
pinesol_green |
Launchpad bug 1717350 in OpenSRF "Upgrading to OpenSRF 2.5.1 appears to break XUL 2.12.5" [High,Confirmed] - Assigned to Galen Charlton (gmc) |
| 17:30 |
gmcharlt |
so... once it (or any improved fix) gets merged, I'll plan on cutting 2.5.2 PDQ |
| 17:33 |
|
Stompro joined #evergreen |
| 17:34 |
|
jvwoolf left #evergreen |
| 17:39 |
dbwells |
gmcharlt's bug is the killer, but FWIW, I think we also have another issue with that loop. We're looping until num_bytes, but still chunking on chars. Since bytes >= chars, the effect will be possible empty responses at the end of the loop (rather than missing data, and depending on chunk boundary), so not the end of the world. If anyone agrees with this diagnosis, I can open a bug about it for a future fix. |
| 17:39 |
gmcharlt |
dbwells: I think it's worth exploring |
| 17:40 |
miker |
yeah, breaking when the substr is empty seems sane |
| 17:43 |
dbwells |
Okay, I will try to concoct a test case and go from there. I'm not very familiar with this layer, so should be interesting at least :) |
| 17:45 |
miker |
hrm... I wonder if the C version is at risk of spliting 2+ byte utf8 chars ... I suspect so. I'll make a note to look at that first thing tomorrow. |
| 17:46 |
* miker |
shakes fist at the heavens, "U T F EEEEEEIIIIIGGGGGHHHHTTTTT!" |
| 17:53 |
miker |
actually, nevermind. we \u-encode 2+ byte chars |
| 17:53 |
miker |
and it's all just a string until PartialComplete arrives |
| 17:54 |
miker |
so, really, bytes == chars on the perl side |
| 17:54 |
miker |
(and the C side ... on both sides) |
| 17:55 |
miker |
anyway, chars vs bytes isn't actually a thing for us once we've created a JSON string |
| 17:56 |
dbwells |
miker: Is it tomorrow already? :) |
| 17:57 |
miker |
YES ;) |
| 17:57 |
dbwells |
miker: so does that mean this commit isn't needed? http://git.evergreen-ils.org/?p=OpenSRF.git;a=commitdiff;h=be2b2645f7da0907366eb0c99b5d6c231c366b30 |
| 17:57 |
pinesol_green |
dbwells: [opensrf|Bill Erickson] LP#1709710 Count Perl chunk/bundle sizes in bytes - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=be2b264> |
| 17:58 |
berick |
miker++ |
| 17:58 |
berick |
i think we can revert that commit |
| 17:58 |
miker |
dbwells: yes, that's correct. it's not necessary. I'm inclined to request we remove it and replace it with a comment about our \u-escaping to avoid future us'es from tripping over this again ;) |
| 17:58 |
miker |
however, I think int-ifying the result of the division is still worth having |
| 17:59 |
dbwells |
miker++ thanks for the research and explanations, one less to-do for me tomorrow as well |
| 17:59 |
miker |
we /are/ doing that in the C code (via casting) |
| 18:00 |
miker |
s/worth having/probably necessary/ |
| 18:01 |
miker |
I'm about to turn into a pumpkin, but if nobody beats me to it, I'll branchify in the morn' |
| 18:12 |
|
RyanM joined #evergreen |
| 18:14 |
RyanM |
Hey all...Is there any way, in Evergreen version 2.11.1, to stabilize andn organize the available search fields in the "Import Record from Z39.50" function? |
| 18:14 |
RyanM |
On every PC in my library, these fields shift position every time you load that particular function up, and it's driving some of the staff nuts! |
| 20:35 |
pinesol_green |
[opensrf|Galen Charlton] LP#1717350: fix chunking messages sent from Perl services - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=1f38166> |
| 20:46 |
|
LinusUrban joined #evergreen |
| 21:14 |
|
tsbere joined #evergreen |
| 21:15 |
|
abowling joined #evergreen |
| 22:42 |
pinesol_green |
[evergreen|Jane Sandberg] Docs reorg: adding OPAC chapter to all relevant manuals - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=672bdb7> |
| 23:38 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1716475: Add label for mobile carrier select menu - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c0222f5> |
