| 00:25 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:19 |
|
agoben joined #evergreen |
| 07:48 |
|
gsams__ joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:00 |
|
idjit joined #evergreen |
| 09:12 |
dbwells |
csharp: I am not aware of docs, but I'll answer best I can. 1) No third person is needed, unless you think the patch could use a third signoff. 2) If it is a bugfix and it merges cleanly, I almost always backport. If it is borderline or the merge isn't easy/obvious, I'll try to create a branch with the edited backport commit, but will leave it to the release maintainer or others to push in. |
| 09:15 |
Dyrcona |
Additional sign offs are encouraged if there are no tests or test plan. |
| 09:16 |
dbwells |
csharp: For 3.1 webstaff fixes in particular, I am going to lean in the direction of calling things bugfixes (and therefore backport) unless it is very obviously a new feature. |
| 09:16 |
|
kmlussier joined #evergreen |
| 09:17 |
Dyrcona |
I'll usually backport if it is a bugfix, the bug is targeted, and any merge conflicts are obvious to resolve. |
| 10:09 |
mmorgan |
Dyrcona: Does action_trigger.event.add_time help with the "date" of the event? |
| 10:10 |
Dyrcona |
No, because I have bills for events from before the migration being generated. |
| 10:10 |
Dyrcona |
I should have really thought this through and added a max_delay before doing the delete. |
| 10:11 |
Dyrcona |
That's what happens when you test something on a system not running action trigger cron jobs. |
| 10:12 |
Dyrcona |
I ran this last night: https://pastebin.com/34t5AY1z |
| 10:13 |
Dyrcona |
I figured I was shutting things down for an OpenSRF update, so why not? ..... :/ |
| 10:16 |
jeffdavis |
Dyrcona: action_trigger.hook has a core_type field if that helps |
| 10:40 |
jeffdavis |
a difference of 10000 units approximately |
| 10:40 |
berick |
yeah |
| 10:40 |
berick |
not simultaneous |
| 10:40 |
csharp |
I don't have a key for ccs in my test server's offline DB right now |
| 10:40 |
csharp |
what adds it? |
| 10:41 |
* csharp |
tried circulating an item |
| 10:42 |
berick |
yeah, looks like copy satuses are fleshed during checkout |
| 10:42 |
jeffdavis |
I did a checkin, then a checkout, then hit F1 and got the white screen at that point |
| 10:42 |
berick |
and at that point likely get addded to offline cache |
| 11:51 |
* kmlussier |
still can't replicate it following jeffdavis' steps |
| 11:52 |
csharp |
kmlussier: jeffdavis: I wasn't able to replicate it either :-/ |
| 11:52 |
jeffdavis |
:( |
| 11:52 |
csharp |
my test server is apparently borked, JS-wise - I keep getting partially loading UIs and "blah is not a function" errors :-/ |
| 11:53 |
csharp |
gonna blow it away and start a new one I think |
| 11:53 |
* berick |
is reminded of https://developers.google.com/web/updates/2016/06/persistent-storage |
| 11:55 |
jeffdavis |
A second person was able to reproduce the white screen with those steps in our environment. Interesting that it doesn't work elsewhere. |
| 11:58 |
|
gsams joined #evergreen |
| 12:01 |
kmlussier |
jeffdavis: I just replicated it on another server following your steps. The other environment is on 3.0 (I was previously testing on 3.1) and has production data instead of Concerto. |
| 12:02 |
kmlussier |
I wonder if I was able to replicate it more easily because, with production data, the transactions move a little more slowly, allowing me to get the timing right? |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:02 |
jeffdavis |
Oh neat! Yeah, I am seeing it in production with 3.1.0 (+ many backports). |
| 12:05 |
jeffdavis |
I realize it's a little weird to be excited that something *isn't* working... |
| 12:25 |
pinesol_green |
Launchpad bug 1727557 in Evergreen 3.1 "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 |
| 12:26 |
berick |
but it would be simple enough to confirm if a reject() alone will allow the browser to continue... |
| 12:26 |
pastebot |
"berick" at 64.57.241.14 pasted "offline db connect promise reject" (20 lines) at http://paste.evergreen-ils.org/9096 |
| 12:27 |
berick |
jeffdavis: kmlussier: could either of you test this patch? ^-- just wondering if we can let the browser recover from the error |
| 12:27 |
sandbergja |
jihpringle++ |
| 12:27 |
sandbergja |
kmlussier++ |
| 12:27 |
sandbergja |
You are all so great! |
| 12:27 |
berick |
we still need to fix the db, of course, but maybe we can buy a little time |
| 12:27 |
kmlussier |
berick: Unfortunately, the test system where I can load patches is not the one where I was able to replicate the problem. |
| 12:28 |
* berick |
nods |
| 12:32 |
jeffdavis |
confirmed the duplicate keys error on a test server, I'll give that patch a try |
| 12:36 |
jeffdavis |
berick: I still get the white screen with that patch |
| 12:37 |
berick |
jeffdavis: ah well, thanks for testing |
| 12:37 |
jeffdavis |
on the plus side, in the test environment the error is pinpointed to lovefield.js:78 if that helps |
| 12:38 |
berick |
it does |
| 12:40 |
jeffdavis |
(that's the line immediately before the first deferred.reject() from your patch in case our line numbers are out of sync) |
| 12:41 |
berick |
oh, just recreated the error |
| 13:11 |
Dyrcona |
I'll update the bug with strace output. |
| 13:13 |
* Dyrcona |
makes absolutely certain that the jchampio branch is installed on all of the bricks as well. |
| 13:14 |
Dyrcona |
It is. |
| 13:16 |
jeffdavis |
berick: for that white screen patch, I wonder if we should notify the user somehow that their offline DB is corrupt. |
| 13:17 |
jeffdavis |
I'm getting ahead of myself though, I should test the patch first. :) |
| 13:18 |
idjit |
the patch for bug 1775216 involves a change to a database function, so i'm guessing i should add a pgtap test for it. unfortunately, while i can execute pgtap and run all the existing tests and verify they pass, i have no idea what i'm doing when it comes to writing new test cases. any guidance? |
| 13:18 |
kmlussier |
jeffdavis: berick: Yes, I was thinking along the same lines. Although I think it's a good thing to get rid of the white screens, my concern is that users happily use the system until it goes down one day, and then they are unable to use offline. |
| 13:18 |
pinesol_green |
Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216 |
| 13:19 |
kmlussier |
berick: Do you expect it will take a long time to address the long-term fix for that issue? |
| 01:33 |
|
RBecker joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:59 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:25 |
|
stephengwills joined #evergreen |
| 15:11 |
* Dyrcona |
forgot about the meeting.... |
| 15:11 |
gmcharlt |
not that 1725317 isn't also a concern... but I think that has the potential to turn into something that warrants a /3.1.0/, as fixing it for real would entail updating some client javascript code |
| 15:11 |
Dyrcona |
#info Dyrcona is Jason Stephenson CW MARS |
| 15:12 |
Dyrcona |
On the topic at hand, I am testing that fix in production starting tonight. |
| 15:12 |
gmcharlt |
Dyrcona++ |
| 15:12 |
gmcharlt |
and also things like bug 1729610 might call for a 3.1 |
| 15:12 |
pinesol_green |
Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610 |
| 15:17 |
gmcharlt |
ok |
| 15:17 |
miker |
anyone want to volunteer to look for (at least) perl and C libs to leverage, either that hand the caller a socket (ideally) or manage the SASL stuff for us given a socket? |
| 15:17 |
csharp |
I think 18.04 support is a reasonable goal for the next release, but I know there are higher priorities |
| 15:18 |
gmcharlt |
#action gmcharlt will do a bugfix release of OpenSRF 3.0.2, particularly upon successful testing of bug 1774703 |
| 15:18 |
pinesol_green |
Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703 |
| 15:18 |
miker |
(and, can we target a version of ejabberd, rather than a disto release? |
| 15:18 |
gmcharlt |
#action gmcharlt will put out a call for roadmap entries for OpenSRF 3.1.0 |
| 15:36 |
berick |
how can I better expose what I'm working on? do we need a temporary repository? should I migrate my branch to a collab branch? |
| 15:36 |
csharp |
gitlab! |
| 15:36 |
berick |
it does take a little getting used to, so I'd like to avoid as many surprises as possible |
| 15:37 |
* csharp |
plans to install berick's branch on his test/dev server this week |
| 15:37 |
berick |
csharp: cool, holler if I can help |
| 15:37 |
csharp |
will do |
| 15:37 |
gmcharlt |
berick: +1 to a collab branch |
| 15:38 |
gmcharlt |
berick: and would it be useful to call a special IRC meeting? |
| 15:38 |
gmcharlt |
or a webinar from which you could do a show-and-tell? |
| 15:38 |
Dyrcona |
csharp: I tried upgrading node on an existing vm and got nothing but errors afterward. |
| 15:39 |
Dyrcona |
This was related to testing the ang6 branch. I have not had time to go back and try again. |
| 15:39 |
csharp |
Dyrcona: ah - good to know |
| 15:39 |
berick |
gmcharlt: i would be happy to participate |
| 15:39 |
gmcharlt |
ok |
| 15:42 |
JBoyer |
Did I not pullrequest it? It's done. |
| 15:43 |
gmcharlt |
ah, cool |
| 15:43 |
berick |
JBoyer: oh, cool, i missed that |
| 15:43 |
* csharp |
still hasn't arranged a good environment to test JBoyer's branch on Windows |
| 15:43 |
gmcharlt |
#info the Firefox add-on for Hatch is available |
| 15:43 |
JBoyer |
Not merged and not updated, but I've seen the printer list in both browsers simultaneously. |
| 15:43 |
JBoyer |
updated -> uploaded. |
| 16:41 |
hbrennan |
permissions experts.... what is the permission to asign access to Local > Hold Policies? I can't find it..... |
| 16:42 |
hbrennan |
search for "hold" in the lists of evergreen permissions isn't coming up with anything |
| 16:43 |
berick |
would it be ADMIN_HOLD_MATRIX_MATCHPOINT ? |
| 16:59 |
csharp |
JBoyer: it's the "no Windows nearby" issue - I'll find something to test with tomorrow :-) |
| 16:59 |
hbrennan |
berick: Thanks. Will try that. |
| 16:59 |
gmcharlt |
csharp: that thing that is both a problem... and gloriously not a problem ;) |
| 17:08 |
|
mmorgan left #evergreen |
| 17:16 |
berick |
i know what the sql is, you'd need to look at what the SQL returns and see if the rows are correctly sorted in the DB |
| 17:20 |
csharp |
berick: I can help |
| 17:21 |
csharp |
yeah, we log statements, so we can get them, but if you already know something I can run... |
| 17:22 |
berick |
csharp: it would be good for you to test whatever SQL is coming over the wire there |
| 17:23 |
berick |
just run the sql in psql and reivew the output and see if it matches the issues reported in the UI |
| 17:23 |
berick |
or if the output looks right where the UI looks wrong |
| 17:23 |
berick |
csharp++ |
| 17:24 |
berick |
huh, no way to mark an LP as done/complete/mission-accomplished short of marking it fix released. |
| 17:24 |
berick |
which is odd when there's no code |
| 17:24 |
berick |
oh well |
| 17:25 |
gmcharlt |
"this fix is too large to be contained within the confines of this tarball..." |
| 17:29 |
berick |
:) |
| 17:29 |
berick |
also known as the "You're not the boss of me" status |
| 18:10 |
berick |
oh well, will revisit tomorrow |
| 18:10 |
csharp |
berick: k - thanks! |
| 18:10 |
berick |
thanks csharp |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
dickreckard left #evergreen |
| 06:13 |
|
Bmagic_ joined #evergreen |
| 06:16 |
|
jeff_ joined #evergreen |
| 06:16 |
|
tsadok joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 12:55 |
JBoyer |
This is a large enough problem that you're never going to have to make more than 1 correction. (unless we adopt all of the MODS versions between 3.2 and 3.6 at once and for some bizarre reason add field entries for more than one in a single upgrade script) |
| 12:56 |
Dyrcona |
Yeah, what JBoyer said. :P |
| 12:56 |
csharp |
ok - sounds sane - thanks |
| 12:57 |
JBoyer |
It's also been tested just today, if you take my meaning, heh. |
| 12:59 |
|
khuckins_ joined #evergreen |
| 13:00 |
jeffdavis |
xpath doesn't need to be updated at all so regexp_replace isn't really required, format just needs to be set correctly |
| 13:02 |
dbs |
aha, oh yay we have lots of mods32 columns too. Curse our 1.6-ish roots |
| 13:06 |
jeffdavis |
JBoyer: looks to me like a fresh install contains a mix of mods32 and mods33 cmf entries |
| 13:07 |
JBoyer |
Ok. So it is a mix, but I doubt they *need* to be different versions. |
| 13:08 |
Jaswinder |
thanks! |
| 13:10 |
JBoyer |
(I get it though, any change will need testing and do you try to go all the way to "current" and so on and etc., also tuits...) |
| 13:12 |
Jaswinder |
Dyrcona: I can call the db using the cstore but I can't find an example to filter only two columns |
| 13:14 |
Dyrcona |
Jaswinder: { "select": { "cmc": [ "name", "label"] "from" : "cmc"} # Off the top of my head. |
| 13:14 |
Dyrcona |
oops.... |
| 13:15 |
Dyrcona |
You might need to convert that to Perl hashref syntax depending on what method you use to run it. |
| 13:20 |
csharp |
Jaswinder: dbs: then my branch for bug 1764542 may be off then |
| 13:20 |
pinesol_green |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Confirmed] https://launchpad.net/bugs/1764542 |
| 13:20 |
csharp |
I just did _bott_'s regexp_replace and updated the format columns for any with mods32 |
| 13:21 |
csharp |
(haven't made that change in production, just on a test server) |
| 13:21 |
Dyrcona |
jeffdavis: ^^ I think csharp meant to be talking to you. :) |
| 13:21 |
csharp |
Dyrcona: yeah - sorry Jaswinder |
| 13:22 |
|
bdljohn joined #evergreen |
| 16:38 |
|
jvwoolf left #evergreen |
| 17:03 |
csharp |
bug 1710293 is one of those where I want to help do that kind of work/cleanup, but I'm not exactly sure what to do in a couple of cases - should I just give it a go with the hope that miker or someone will review it and correct me or is it better to just leave it for someone else? :-) |
| 17:03 |
pinesol_green |
Launchpad bug 1710293 in Evergreen 3.1 "Remaining chunk/bundle work" [Medium,New] https://launchpad.net/bugs/1710293 |
| 17:07 |
miker |
csharp: max_chunk_count should def be spelled max_bundle_count, and the stuff in the ->can() tests can go away now (3.0+) ... and max_chunk_size=>0 should also change as described. I don't think there are any gotchas there (pending testing, obv) if you have the tuits to spare! |
| 17:08 |
csharp |
miker: cool - thanks - I'll give it a shot :-) |
| 17:09 |
|
mmorgan left #evergreen |
| 17:09 |
miker |
csharp++ |
| 17:32 |
gsams |
I'm excited and hopeful, even though it's like a tiny change, but I just pushed a fix. |
| 17:36 |
idjit |
is there a suite of unit tests i should be running prior to submitting pullrequests for things like bug 1724348 or bug 1743801? |
| 17:36 |
pinesol_green |
Launchpad bug 1724348 in Evergreen "Web client: set default view not sticky" [Undecided,Confirmed] https://launchpad.net/bugs/1724348 |
| 17:36 |
pinesol_green |
Launchpad bug 1743801 in Evergreen 3.0 "web client: item status list view display issues" [High,Confirmed] https://launchpad.net/bugs/1743801 |
| 18:17 |
jeffdavis |
idjit: there are some unit tests in Open-ILS/web/js/ui/default/staff/test but I don't know how well they can catch bugs like those two |
| 18:18 |
jeffdavis |
IIRC: `cd Open-ILS/web/js/ui/default/staff && npm run build && npm run test` |
| 18:19 |
idjit |
thanks! running now |
| 18:20 |
idjit |
well, at least my changes didn't break any of the existing tests. :-) |
| 18:20 |
idjit |
jeffdavis++ |
| 18:23 |
idjit |
hey, while you're here, do you remember bug 1761276? i get a new behavior as of this morning. it pulls up a blank page, with the javascript error "Uncaught TypeError: payload.statusCode is not a function". do you see similar? |
| 18:23 |
pinesol_green |
Launchpad bug 1761276 in Evergreen "Odd behaviour when clicking on title hyperlink " [High,Confirmed] https://launchpad.net/bugs/1761276 |
| 18:24 |
idjit |
(i get this when clicking the title on the "item status" page) |
| 18:28 |
jeffdavis |
I haven't seen that one. Is that on master? |
| 18:29 |
idjit |
i think so. i'm not sure, was hoping someone else could help confirm. |
| 18:30 |
|
beanjammin joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:33 |
jeffdavis |
I don't have a test env with master handy, will need to set one up first |
| 18:34 |
idjit |
ok, nevermind. i must've screwed something up this morning. i'm back on master branch now and i get the reported behavior. |
| 19:09 |
|
beanjammin joined #evergreen |
| 19:58 |
|
JBoyer joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 09:06 |
|
idjit joined #evergreen |
| 09:29 |
|
Dyrcona joined #evergreen |
| 09:30 |
Dyrcona |
I know that likely very few people are paying attention, but this is so bizarre I have to share. |
| 09:31 |
Dyrcona |
I successfully ran the pgtap tests in t this morning, but I also ran the perl live tests beforehand so the pgtap livet_t test failed. |
| 09:32 |
Dyrcona |
Oh... Another case of me being an idiot..... |
| 09:32 |
Dyrcona |
I was typing 'So, reload the database....' and realized my problem. |
| 09:32 |
Dyrcona |
No tap extension in the db. ;) |
| 09:38 |
dbs |
don't worry, i was paying attention :) |
| 09:38 |
Dyrcona |
hah! |
| 09:39 |
* dbs |
upgraded to 3.1.2 last night, still running pingest but most things appear to be in decent shape |
| 09:39 |
Dyrcona |
It's funny, 'cause I remembered to create extension pgtap the first time I reloaded the db before running the tests. |
| 09:39 |
Dyrcona |
dbs: Cool. Did you apply berick's patch from bug 1774703? |
| 09:39 |
pinesol_green |
Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703 |
| 09:40 |
Dyrcona |
I'm looking at it this morning and thought I'd run all the tests while I'm at it. |
| 09:42 |
dbs |
Dyrcona: I did not, it seemed like too much of a stretch last night |
| 09:42 |
dbs |
Trying to be somewhat conservative before taking off for a while |
| 09:43 |
Dyrcona |
Makes sense. |
| 09:43 |
Dyrcona |
I'm going to put it on a test vm with our custom 3.0 branch and real data and try some things with it. |
| 09:44 |
Dyrcona |
If nothing goes horribly wrong, I'll see about installing it in production next week. |
| 09:46 |
Dyrcona |
This has been hard to reproduce because it seems to require a load on the server. |
| 09:46 |
Dyrcona |
I did find one segmentation fault in the logs on my test vm from Wednesday, 23 May, when we were testing rather heavily for the upgrade. |
| 09:49 |
Dyrcona |
S'pose I could write a bot to hammer the OPAC... |
| 09:50 |
csharp |
dbs++ # congrats |
| 09:56 |
Dyrcona |
csharp: Dunno if you've tried, yet, but the jchampio apache-websocket seems to work. I've applied berick's branch to a master vm, but I'm going to test with real data next. |
| 09:56 |
dbs |
Dyrcona++ |
| 09:57 |
dbs |
right now our only issue seems to be our LDAP authentication, for no apparent reason. *shrug* |
| 09:57 |
dbs |
I'm sure that many more will turn up though :) |
| 09:59 |
Dyrcona |
dbs++ |
| 09:59 |
Dyrcona |
We've had a lot of tickets on our internal ticket system since the 3.0 upgrade. |
| 09:59 |
Dyrcona |
berick++ |
| 10:02 |
dbs |
well, the load testing at this point is just me (libraries are all closed on the weekend) and even the XUL staff client feels slower as I watch fields populate in the patron screen, etc, so Monday will be the real test |
| 10:03 |
Dyrcona |
That could be the ingest. |
| 10:04 |
Dyrcona |
I noticed that things seem slower while the authority update happens. |
| 10:04 |
Dyrcona |
mixed-tenses-- |
| 10:09 |
Dyrcona |
Checked Nagios and we've got 1 apache2-websockets process using 200% cpu on brick 4. |
| 10:09 |
Dyrcona |
I'm gonna try to strace it for grins before I kill it. |
| 10:11 |
Dyrcona |
So, two in "x32 mode" and 1 waiting on futex. Typical.... |
| 10:14 |
Dyrcona |
hm... This isn't good. I get a blank login screen on my test vm with real data. |
| 10:16 |
Dyrcona |
Ok. It's the origin check. |
| 10:17 |
Dyrcona |
At least, I think so. |
| 10:22 |
Dyrcona |
Hm... changing ServerName in the configs to the fqdn did not fix it.... |
| 10:29 |
dbs |
pretty wild discrepancy :) |
| 10:31 |
Dyrcona |
I mainly see a difference with RAM on the server. |
| 10:31 |
Dyrcona |
It runs fast on production because that server has enough RAM to load our entire DB. |
| 10:31 |
Dyrcona |
It runs slower on the test DB server because it doesn't, and it has more than 1 database. |
| 10:32 |
dbs |
.... and I just hit CTRL-C on the pingest process. gah. |
| 10:32 |
Dyrcona |
I also find things are faster on the test DB server in databases that have been freshly loaded. |
| 10:32 |
dbs |
yeah, our test & prod db servers are identically specced, so it's all about the lack of bloat I think |
| 10:32 |
Dyrcona |
Gah! If that was unintentional. |
| 10:33 |
Dyrcona |
Yeah. |
| 10:33 |
dbs |
yeah, meant CTRL-Shift-C because Google Docs doesn't accept pastes from the middle button clipboard for some reason :/ |
| 10:33 |
dbs |
but missed the shift |
| 10:34 |
* dbs |
runs a few reindexes to reduce index bloat before kicking that off again |
| 10:34 |
Dyrcona |
yeah, I've noticed that lack of middle button paste. |
| 10:35 |
Dyrcona |
Our test db server used to be a mail server. It has 128Gb of RAM and 6TB of disk space, so a decent choice for storing multiple copies of production data and other, assorted databases. |
| 10:35 |
Dyrcona |
Gb should have been GB. |
| 10:36 |
dbs |
you could use "GO" for giga-octets |
| 10:37 |
Dyrcona |
I wonder if I blow my copy templates our and replace them with someone else's if that will "work" in the web staff client. |
| 10:52 |
Dyrcona |
I don't recall there being an order by on the standard query. |
| 10:53 |
Dyrcona |
BTW, bug 1768715 has a branch, now. |
| 10:53 |
pinesol_green |
Launchpad bug 1768715 in Evergreen "Add pingest.pl to evergreen" [Wishlist,Confirmed] https://launchpad.net/bugs/1768715 |
| 10:54 |
Dyrcona |
Oops. I wanted to delete just cat.copy_templates from local storage and ended up deleting all of my local storage for the test vm. |
| 10:54 |
Dyrcona |
NBD....I suppose. |
| 10:55 |
Dyrcona |
dbs: Turns out there is: ORDER by id ASC |
| 10:55 |
Dyrcona |
So, you could just --start-id=. |
| 11:12 |
Dyrcona |
The browse ingest is special and does all the records in a single process since it cannot be run in parallel with itself, so it's an exception, sort of. |
| 11:13 |
Dyrcona |
I'm not sure the browse is required for 3.1. I haven't looked and guess it depends where you're starting from. |
| 11:14 |
Dyrcona |
It is not required to go from 2.12 to 3.0. |
| 11:14 |
Dyrcona |
RE copy templates: I think I'll copy the copy templates from the user who has the most into mine for the sake of testing. |
| 11:27 |
Dyrcona |
Hmm... The copy templates were not converted. |
| 11:28 |
dbs |
ruh-roh |
| 11:28 |
* dbs |
notes that there are Hatch install instructions on Windows and Linux, but nothing for MacOS - has anyone got that particular combo working? |
| 11:56 |
dbs |
Dyrcona++ |
| 11:57 |
Dyrcona |
YW. |
| 11:57 |
Dyrcona |
I wonder if I should be concerned about this: Unable to fopen log file /openils/var/log/gateway.log for writing; logging to standard error |
| 11:57 |
Dyrcona |
It appears in my apache2-websockets error.log on my test vm. I think it has to do with a configuration issue, i.e. syslog vs non-syslog. |
| 11:58 |
Dyrcona |
Except /openils/var/log/gateway.log is there. |
| 12:00 |
Dyrcona |
It appears in most of my logs on this vm. |
| 12:00 |
* Dyrcona |
check a production server, but doesn't recall seeing it there. |
| 12:01 |
Dyrcona |
Yeah, doesn't happen in production. I'll ignore it. :) |
| 14:11 |
jeffdavis |
dbs: we've been seeing a lot of those search.highlight_display_fields errors too but I haven't traced it to an actual display problem so far |
| 14:12 |
jeffdavis |
if it worked in testing maybe it's a schema problem with the hstore type? |
| 14:23 |
dbs |
jeffdavis: good thought! I guess we'll see :) |
| 14:23 |
dbs |
I can see records where the matches are highlighted, and matches where they're not, so it seemed related to the ingest |
| 14:56 |
|
dan_learns joined #evergreen |
| 17:10 |
* Dyrcona |
signs out. |
| 18:14 |
|
Dyrcona joined #evergreen |
| 18:14 |
Dyrcona |
OK, not my whole day, just most of it. |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:41 |
dbs |
interesting, a display-only reingest via pingest doesn't populate metabib.display_entry, but a full reingest does |
| 18:41 |
* dbs |
adds a custom '''$where .= " AND NOT EXISTS (SELECT source FROM metabib.display_entry WHERE source = biblio.record_entry.id)"; |
| 18:42 |
dbs |
to reingest only the records with an empty metabib.display_entry (those do seem to be the cause of the search.highlight_display_field errors) |
| 19:04 |
Dyrcona |
I think it was a report, but I don't know which of the 3 that were running at the time, because it looks like the query for the culprit PID was not logged. |
| 19:05 |
Dyrcona |
dbs: You're right about metabib.reingest_metabib_field_entries... But, it should still work if you skip everything but display. |
| 19:06 |
Dyrcona |
If not, then I'd say that's a bug in the db function. |
| 19:13 |
dbs |
yeah. right now if you skip everything but display in pingest, it skips doing anything (need to add && skip_display to the if condition before reingest) |
| 19:13 |
dbs |
but even if you add that && skip_display test, so it runs reingest with just display enabled, it goes way too fast :) |
| 19:15 |
Dyrcona |
OIC: bug on line 205 of pingest.pl. dbs++ |
| 19:16 |
Dyrcona |
And on line 274! |
| 19:16 |
Dyrcona |
So, guess I'll fix both the github repo and the branch for Lp. |
| 19:21 |
dbs |
Ah, that's what line 274 would have caused. Perfect! |
| 19:21 |
dbs |
thank you! |
| 19:21 |
Dyrcona |
Thank you! |
| 19:23 |
Dyrcona |
I never tested with everything but display skipped, I guess. |
| 19:37 |
Dyrcona |
hmm. One drawback of adding pingest.pl to evergreen is the way I've done the branch by copying the latest version of the file. |
| 19:37 |
Dyrcona |
It loses the history of commits from berick, Bmagic, and jeff.... |
| 19:37 |
Dyrcona |
Maybe I should redo it? |
| 03:47 |
|
bshum joined #evergreen |
| 03:47 |
|
pastebot joined #evergreen |
| 04:44 |
|
gsams joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
rlefaive joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:48 |
|
rjackson_isl joined #evergreen |
| 09:51 |
Dyrcona |
I'm looking at the options for ps more closely and doing strace on some threads that are working. |
| 09:51 |
Dyrcona |
Mostly they block in select or accept. |
| 09:51 |
|
mmorgan1 joined #evergreen |
| 09:52 |
* csharp |
doesn't have any spinning procs at the moment, but will test along with for comparison |
| 09:52 |
|
mmorgan2 joined #evergreen |
| 09:52 |
Dyrcona |
I'm not looking at spinning processes. I'm actually looking at idle websocket workers. |
| 09:53 |
|
mmorgan3 joined #evergreen |
| 11:37 |
Dyrcona |
NFPL: To change the password in the database now, you have to get a salt, then update the password with a db function. |
| 11:38 |
* Dyrcona |
will post his custom function to make it easier later. |
| 11:38 |
Dyrcona |
I was looking at https://github.com/disconnect/apache-websocket/pull/39 which might also be relevant since we're using mpm_prefork. |
| 11:39 |
Dyrcona |
The jchampio repository is definitely worth a look. I can test it on a vm soonish. |
| 11:41 |
Dyrcona |
In fact, I'll do it now. |
| 11:41 |
Dyrcona |
Well, get started now anyway. |
| 11:43 |
* berick |
is trying it too |
| 11:47 |
berick |
Dyrcona: beware it's more strict about checking the origin. on my test VM I set WebSocketOriginCheck Off in the websocket apache config (because my Host doesn't match the apache host). presumably not an issue on a real setup |
| 11:47 |
berick |
it also supports whitelists, fyi |
| 11:47 |
Dyrcona |
And, I see something about plugins. |
| 11:47 |
berick |
otherwise, it seems to work as before, though |
| 11:47 |
berick |
well, our osrf code is a "plugin" |
| 12:23 |
Dyrcona |
Well, so far, so good. |
| 12:23 |
Dyrcona |
I've logged in and added a volume and copy to a bib record with the web staff client. |
| 12:24 |
berick |
interestingly, i'm having issues with the new code. but the issues look similar to what you have been reporting. I don't get the CPU spike, but I can make the process lock up. tracking that down now... |
| 12:26 |
Dyrcona |
OK. I just checked the book out to myself. Are there automated tests that should be run? |
| 12:28 |
berick |
there's no automated tests for websockets gateway |
| 12:30 |
Dyrcona |
Worth asking, just in case. :) |
| 12:42 |
|
jihpringle joined #evergreen |
| 12:44 |
|
kmlussier joined #evergreen |
| 12:58 |
jeff |
berick, Dyrcona: what distro are you each testing on? |
| 12:58 |
Dyrcona |
Ubuntu 16.04, so is our production. |
| 12:58 |
Dyrcona |
I've been pulled away to something else at the moment. |
| 13:10 |
|
kmlussier joined #evergreen |
| 16:13 |
jihpringle |
frank_g: was the template created in the xul client or the web client? |
| 16:14 |
frank_g |
xul client |
| 16:14 |
jihpringle |
templates created in the xul client cannot currently be cloned in the web client |
| 16:14 |
frank_g |
ahh ok, that responses my question, let my try creating a new template and then cloning it |
| 16:16 |
frank_g |
jihpringle: yes, I tested it, thanks for your help |
| 16:17 |
jihpringle |
you're welcome |
| 16:17 |
David |
Hi, I am having an issue with accessing data that comes back from pcrud class inside the template. I am put the code and the output here. Can someone help as how I can access the data? |
| 16:17 |
pastebot |
"david" at 64.57.241.14 pasted "Need to access the values inside the bless section" (9 lines) at http://paste.evergreen-ils.org/6687 |
| 16:44 |
kmlussier |
jihpringle: OK, good to know. I guess that makes it even more critical for the other fix to get in then. |
| 17:03 |
|
mmorgan left #evergreen |
| 17:17 |
|
jvwoolf left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:59 |
dbs |
@later tell dbwells We seem to be missing the 3.1.1-3.1.2 version upgrade script in git? |
| 20:59 |
pinesol_green |
dbs: The operation succeeded. |
| 02:54 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:40 |
|
rlefaive joined #evergreen |
| 08:53 |
* Dyrcona |
wonders if he should ask in here or in #postgresql..... |
| 08:53 |
Dyrcona |
But, first, a paste! |
| 09:01 |
Dyrcona |
So, I came up with this script to remove old action_trigger events and event output this week: https://pastebin.com/34t5AY1z |
| 09:02 |
Dyrcona |
I have tested it on a copy of production data from Wednesday around midnight. |
| 09:02 |
Dyrcona |
It works, and it drops about 30GB of useless data from our database. |
| 09:03 |
Dyrcona |
My question is, when I run this in production, should I shut down cron jobs and anything else that may touch the action_trigger tables while it runs? |
| 09:03 |
Dyrcona |
Or, will normal database locking take care of any problems? |
| 09:04 |
Dyrcona |
My final, working, test ran in about 6 minutes 46 seconds on my test db server. |
| 09:06 |
|
jvwoolf joined #evergreen |
| 09:08 |
|
jvwoolf1 joined #evergreen |
| 09:12 |
|
lsach joined #evergreen |
| 09:33 |
Dyrcona |
Oh, good. Postgres died on the replicant server.... |
| 09:42 |
Dyrcona |
We've also had some issues with Apache processes spinning with high CPU since the upgrade, and I don't think it's a websockets issue or not the same that was patched, because we are on OpenSRF 3.0.1. |
| 09:47 |
Dyrcona |
Also, Overdrive integration appears to be not working, or sort of not working.... |
| 09:48 |
Dyrcona |
Overdrive's test environment requiring different credentials and configuration from production is less than ideal. |
| 09:56 |
JBoyer |
re: deferrable, it is helpful if you're doing much else in a transaction, but if deleting from action_trigger.evtent_output is the last thing before the commit it doesn't really make a difference. |
| 09:57 |
JBoyer |
Since it's ~20s per ateo for me I'll probably only ever drop constraint; delete; alter table; to clean it up. :/ |
| 09:57 |
|
terran joined #evergreen |
| 09:59 |
Dyrcona |
JBoyer: Ok. Have you tried the cleanup db function and configure the retention_interval? |
| 09:59 |
Dyrcona |
I was wondering if the function would work without deferred constraints. |
| 10:00 |
Dyrcona |
I want to test that but I have more immediate things going on. |
| 10:00 |
berick |
we're using retention_interval locally, but only after a big initial cleanup |
| 10:00 |
berick |
w/ truncates |
| 10:01 |
Bmagic |
Dyrcona++ # nice script |
| 10:41 |
Dyrcona |
More or less. |
| 10:41 |
Dyrcona |
And, yeah, I was thinking February would be special. |
| 10:41 |
miker |
so, we just need to use the constructor that looks like this: var d = new Date(year, month, day, hours, minutes, seconds, milliseconds); |
| 10:41 |
terran |
dbwells: In my testing it didn't matter what the day is |
| 10:42 |
berick |
miker: yeah, that's what I was thinking... |
| 10:42 |
miker |
terran: but it matters what day you test on! :) |
| 10:42 |
dbwells |
terran: right, what miker said :) |
| 10:42 |
terran |
miker: oh! |
| 10:42 |
terran |
:D |
| 10:56 |
Dyrcona |
So, I have apache2-websockets instances spinning out of control. |
| 10:58 |
Dyrcona |
Oh, that's lovely: [Wed May 30 10:53:18.447792 2018] [core:notice] [pid 3491] AH00051: child pid 14598 exit signal Segmentation fault (11), possible coredump in /etc/apache2-websockets |
| 11:00 |
Dyrcona |
Of course, those are dead and not spinning doing nothing. |
| 11:13 |
JBoyer |
Dyrcona, oh, I wasn't following the actual question, I assumed the truncate was a one-time cleanup before using the built-in cleanup. I would assume that deferrable would work, but I wasn't testing that before. I may give that a shot soon. |
| 11:20 |
Dyrcona |
So, we appear to be having issues with websockets. |
| 11:21 |
csharp |
berick++ |
| 11:21 |
Dyrcona |
I guess that's too vague. I'll have to do some research and open a Lp bug. |
| 13:33 |
csharp |
I'm sure we're dealing with massive JSON blobs |
| 13:33 |
Dyrcona |
Well, I'm going to finally kill some of these on one of the bricks. I'm getting load warnings for the brick head, now. |
| 13:33 |
Dyrcona |
I still have 'em spinning on two other bricks if more strace data is needed. |
| 13:35 |
jeffdavis |
It's not consistently reproducible in our environment either. Retrieving the same big JSON blob works sometimes and fails other times. I want to test the specific step of copying XUL templates to the new web client copy template user setting (see the load_remote_acp_templates() function in cat/volcopy/app.js), but haven't had time yet. |
| 13:43 |
Dyrcona |
Wow! |
| 13:44 |
Dyrcona |
One of them is now using 192.7% cpu and refuses to TERM. Time to KILL. |
| 13:44 |
|
rlefaive joined #evergreen |
| 14:11 |
|
jeffdavis joined #evergreen |
| 14:15 |
Dyrcona |
dbs did you identify yourself with bot to add the quote? if not, I can add it. |
| 14:16 |
berick |
strace is not helping me too much, unfortunately. suffice to say if someone can reliably reproduce, I'm all over it. |
| 14:17 |
Dyrcona |
That's the thing. I haven't seen it on a test environment, so I'm not sure what it triggering it. I'll look into the copy templates angle later. |
| 14:21 |
|
kmlussier joined #evergreen |
| 14:25 |
* Dyrcona |
wishes he could copy and paste text from an image, but doesn't have OCR for the clipboard. |
| 14:25 |
* berick |
wishes he could copy/paste from his eyes |
| 17:19 |
|
mmorgan left #evergreen |
| 17:33 |
|
abowling left #evergreen |
| 18:05 |
|
rlefaive joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:30 |
|
rlefaive joined #evergreen |
| 20:16 |
|
book` joined #evergreen |
| 20:25 |
|
rlefaive joined #evergreen |
| 00:58 |
|
fteto joined #evergreen |
| 00:59 |
jeffdavis |
What a jerk. |
| 02:30 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
collum joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 14:52 |
dbs |
I consider the hairs well-split now |
| 14:52 |
dbs |
and will vanish to focus on actually trying to run EG 3.1.1 again |
| 14:54 |
Dyrcona |
:) |
| 14:55 |
* Dyrcona |
prepares to push some more signedoff and tested branches. |
| 14:57 |
kmlussier |
Dyrcona++ |
| 14:57 |
kmlussier |
gmcharlt++ |
| 15:00 |
pinesol_green |
[evergreen|gcollum] LP#1743782 Copy Status not available in Check-In Screen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0eac25e> |
| 15:04 |
pinesol_green |
[evergreen|Garry Collum] LP#1745232 - Bill History Receipt doesn't have Finish Date - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc25b34> |
| 15:08 |
pinesol_green |
[evergreen|Garry Collum] LP#1745240: Hold Alias Missing from Hold Shelf Slip - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=510284d> |
| 15:25 |
|
dkyle1 left #evergreen |
| 15:27 |
idjit |
jeffdavis: what'd you do to test bug 1761276? i can't replicate. i've got patches for bugs 1761276 and 1724348, and suspect you may need them both. |
| 15:27 |
pinesol_green |
Launchpad bug 1761276 in Evergreen "Odd behaviour when clicking on title hyperlink " [High,Confirmed] https://launchpad.net/bugs/1761276 |
| 15:27 |
pinesol_green |
Launchpad bug 1724348 in Evergreen "Web client: set default view not sticky" [Undecided,Confirmed] https://launchpad.net/bugs/1724348 |
| 15:29 |
idjit |
sorry, that should've been be patches for bugs 1731272 and 1724348. |
| 15:36 |
miker |
ah, nevermind :) |
| 15:36 |
miker |
global notice tells the tale |
| 15:40 |
|
rjackson_isl joined #evergreen |
| 15:40 |
jeffdavis |
idjit: It's intermittent so hard to replicate, I think it's more visible when record retrieval is slow. Maybe try clearing cache, then clicking the title hyperlink in record summary. |
| 15:40 |
jeffdavis |
I am definitely interested in testing patches. :) |
| 15:42 |
idjit |
jeffdavis: ok, i'll keep trying. cache gets cleared pretty frequently. i'll see about slowing the connection down. let me know if you figure out a repeatable test. |
| 15:42 |
|
bshum_ joined #evergreen |
| 15:42 |
jeffdavis |
csharp (aka Guest83209): you mentioned yesterday that you were seeing NOT CONNECTED TO THE NETWORK errors possibly related to retrieving XUL copy templates in the web client. Are you also seeing websockets processing stuck at 100% CPU? |
| 15:44 |
pinesol_green |
[evergreen|Mike Rylander] LP#1755220: Return value checking in offline session fetch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23719d9> |
| 17:15 |
jeff |
if the current polling method is timing out due to number of matching patrons, you might consider. i think that PINES and/or EI use the "initiate then poll" method. |
| 17:15 |
jeff |
I'm not recommending that you switch to the penalty method to solve this -- that's a little different overall. |
| 17:15 |
jeff |
(and now that i think of it, i don't know if the penalty method is the only way to do the batch / poll-later method) |
| 17:16 |
Bmagic |
the initial unfleshed set of patrons for my test case is 7100 patrons. Followed by 7100 DB look ups in process_users_of_interest_results which takes more than the 7200 threshold |
| 17:16 |
jeff |
(sorry, on my way afk, so can't be more specific right now.) |
| 17:16 |
Bmagic |
no worries! Thanks! |
| 17:16 |
Bmagic |
jeff++ |
| 17:17 |
Bmagic |
roughly |
| 17:18 |
|
beanjammin joined #evergreen |
| 18:26 |
|
sandbergja joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:57 |
|
beanjammin joined #evergreen |
freenode/staff/exherbo.christel)- [Global Notice] Hi all, you may have noticed that the network is being hit by oh so hilarious (not) spam -- fear not, your passwords are all