| Time |
Nick |
Message |
| 07:36 |
|
Stompro joined #evergreen |
| 07:38 |
|
rjackson_isl joined #evergreen |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:46 |
|
JBoyer joined #evergreen |
| 07:48 |
|
remingtron joined #evergreen |
| 08:02 |
|
ericar joined #evergreen |
| 08:08 |
csharp |
JBoyer: good morning! I'm setting up pgbadger again and I can't recall the magic required to get it to see rsyslog messages as valid syslog - do you have that information handy? |
| 08:08 |
csharp |
google shows basically nothing about this |
| 08:09 |
* csharp |
remembers having to change the date format somehow |
| 08:09 |
* csharp |
remembers having to change the date format somehow |
| 08:09 |
csharp |
oops |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:29 |
kmlussier |
Good morning #evergreen! |
| 08:29 |
JBoyer |
csharp: Indeed. There are 2 things to check, the rsyslog config and the pgbadger command. The most important is the rsyslog config, for local3 you should have this line: "local3.* ?pg" instead of this one: "local3.* ?pg;msgformat" |
| 08:30 |
JBoyer |
The custom msgformat we apply to the rest of the logs looks funny to pdbadger. |
| 08:31 |
JBoyer |
And I was wrong about the pgbadger command line, if you do that, all you need to specify is -f syslog and it's happy. |
| 08:33 |
csharp |
JBoyer: awesome - I'll try that |
| 08:33 |
JBoyer |
I suppose just saying "rsyslog config" isn't terribly specific, That change is on the syslog server, you don't have to touch the db or anything else. |
| 08:49 |
JBoyer |
Interesting you should mention pgbadger, as it's been showing me some TPAC related query that hovers around 90 seconds since our upgrade. Seq Scan on asset.copy for the win! (I suspect we're missing an index or something, but I'm not even entirely certain what it's for..) |
| 08:50 |
|
mmorgan joined #evergreen |
| 08:51 |
JBoyer |
Oh, I found it. It's the query that populates the item information on title detail pages. But it doesn't always take that long. What fun. |
| 09:21 |
|
Dyrcona joined #evergreen |
| 09:23 |
csharp |
JBoyer++ # that did it |
| 09:25 |
JBoyer |
csharp: do you still have the rsyslog changes you need to prevent the rate limiter from dropping queries, or are you only logging queries longer than X time? |
| 09:26 |
JBoyer |
Oh, and also "Good to hear it!" :) |
| 09:28 |
|
ericar_ joined #evergreen |
| 09:32 |
mceraso |
kmlussier++ # Git Day was great! |
| 09:33 |
mceraso |
yboston++ and Dyrcona++ # Thanks for all of your help |
| 09:33 |
Dyrcona |
kmlussier++ # Git day was indeed, great! |
| 09:33 |
kmlussier |
mceraso: I'm so glad you and Jessica could make it! |
| 09:33 |
kmlussier |
Dyrcona++ yboston++ |
| 09:34 |
mceraso |
kmlussier: Absolutely! We were happy to join everyone. It was a fantastic day :) |
| 09:35 |
Dyrcona |
Every time I drive by the library in Hudson, NH, I think of stopping in to say, "Hi!" |
| 09:36 |
Dyrcona |
That's pretty much only when I drive my daughter to school. |
| 09:36 |
kmlussier |
Is Hudson, NH that close? |
| 09:36 |
Dyrcona |
The library is just the other side of Nashua. |
| 09:36 |
kmlussier |
Oh, yeah. I should visit someday |
| 09:37 |
csharp |
JBoyer: no - I don't think the rate limiter stuff is in place |
| 09:37 |
|
yboston joined #evergreen |
| 09:37 |
Dyrcona |
I pass it on RT 111 or 101A, I forget which one it is at that point. |
| 09:38 |
JBoyer |
csharp: If you're interested I can paste those changes somewhere (it's a little more involved) |
| 09:38 |
csharp |
JBoyer: please |
| 09:41 |
|
maryj joined #evergreen |
| 09:46 |
pastebot |
"JBoyer" at 64.57.241.14 pasted "rsyslog config to disable rate limiter" (15 lines) at http://paste.evergreen-ils.org/15 |
| 09:48 |
csharp |
JBoyer++ # awesome, thanks |
| 09:48 |
csharp |
(we have to keep the karma going for your new/old nick ;-)) |
| 09:49 |
csharp |
@karma jboyer-isl |
| 09:49 |
pinesol_green |
csharp: Karma for "jboyer-isl" has been increased 42 times and decreased 0 times for a total karma of 42. |
| 09:49 |
csharp |
@karma JBoyer |
| 09:49 |
pinesol_green |
csharp: Karma for "JBoyer" has been increased 3 times and decreased 0 times for a total karma of 3. |
| 09:51 |
kmlussier |
JBoyer++ |
| 09:57 |
JBoyer |
The trials and tribulations of nick-swapping, I'm a karma newb again. |
| 09:58 |
|
ericar joined #evergreen |
| 10:02 |
kmlussier |
JBoyer: That's why it's good to reset karma every year. Everyone starts all over again. |
| 10:03 |
berick |
JBoyer++ |
| 10:12 |
JBoyer |
42?! apparently jboyer-isl discovered the meaning of life, the universe, and everything. I wish I had written it down. |
| 10:14 |
Dyrcona |
heh |
| 10:18 |
* csharp |
just turned 42 - so far everything is just as mysterious as before |
| 10:20 |
* Dyrcona |
is *mumble* *mumble* years old.... |
| 10:23 |
|
jwoodard joined #evergreen |
| 10:47 |
csharp |
hmm - looks like the new hold_request_capture_protect_idx index is preventing item checkin with no useful errors to the end user |
| 10:48 |
csharp |
duplicate key value violates unique constraint "hold_request_capture_protect_idx" - DETAIL: Key (current_copy)=(14779072) already exists. |
| 10:48 |
csharp |
seems like something the application layer should be testing before it tries to update the hold row |
| 10:49 |
csharp |
rather than failing gracelessly |
| 10:51 |
csharp |
32e415a2 |
| 10:51 |
pinesol_green |
[evergreen|Mike Rylander] LP#902255: Protect against hold double-capture - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=32e415a> |
| 10:51 |
csharp |
hmm |
| 10:51 |
* csharp |
checks that util.js and circ.properties is up-to-date |
| 10:53 |
csharp |
yep - all there |
| 10:57 |
csharp |
yeah - getting that error a lot in the logs |
| 10:57 |
csharp |
2016-01-26 10:53:27 brick02-head open-ils.cstore: [ERR :21015:oils_sql.c:6431:1453823577210003] open-ils.cstore ERROR updating action::hold_request object with id = 15069779: 3505685 3505685: ERROR: duplicate key value violates unique constraint "hold_request_capture_protect_idx"#012DETAIL: Key (current_copy)=(14779072) already exists |
| 10:59 |
|
mllewellyn joined #evergreen |
| 11:07 |
Dyrcona |
csharp: FWIW, I'm not finding that error in my osrfsyslogs, but I only checked the past week or so. |
| 11:08 |
csharp |
hmm - weird |
| 11:09 |
* mmorgan |
is not seeing that error either. |
| 11:09 |
* Dyrcona |
is still on 2.7, though. |
| 11:10 |
mmorgan |
We're 2.9.1, but have hidden the asynchronous checkbox in our client. |
| 11:10 |
Dyrcona |
I have a note somewhere to hide that box, but we haven't done that. |
| 11:11 |
Dyrcona |
A little birdie tells me I wouldn't see it. The change was implemented around 2.8.2. :) |
| 11:11 |
Dyrcona |
bshum++ |
| 11:11 |
* berick |
just hid that checkbox locally as well |
| 11:12 |
csharp |
so it's because of async checkout? or is that another topic? |
| 11:12 |
Dyrcona |
Not sure, really. |
| 11:12 |
berick |
the high for today is 60. I still can't (easily) walk down my driveway. |
| 11:13 |
csharp |
berick: is it uphill both ways? |
| 11:13 |
Dyrcona |
heh |
| 11:13 |
berick |
csharp: it is if you walk backwards half way |
| 11:13 |
csharp |
berick++ |
| 11:14 |
csharp |
oh - duh - I didn't read the commit msg |
| 11:14 |
csharp |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=32e415a |
| 11:14 |
pinesol_green |
[evergreen|Mike Rylander] LP#902255: Protect against hold double-capture - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=32e415a> |
| 11:14 |
Dyrcona |
bshum++ # For something else. |
| 11:17 |
csharp |
help me bshum, you're my only hope |
| 11:18 |
Dyrcona |
heh |
| 11:18 |
bshum |
Thank you csharp! But our princess is in another castle! |
| 11:18 |
JBoyer |
bshum++ |
| 11:18 |
bshum |
@dunno add Thank you $who! But our princess is in another castle! |
| 11:18 |
pinesol_green |
bshum: The operation succeeded. Dunno #47 added. |
| 11:19 |
csharp |
bshum++ |
| 11:19 |
Dyrcona |
@quote get 137 |
| 11:19 |
pinesol_green |
Dyrcona: Quote #137: "<csharp> help me bshum, you're my only hope" (added by Dyrcona at 11:19 AM, January 26, 2016) |
| 11:19 |
Dyrcona |
:) |
| 11:19 |
Dyrcona |
Ok... What was I doing? Oh yeah! |
| 11:22 |
|
vlewis joined #evergreen |
| 11:27 |
kmlussier |
I may have misunderstood, but I didn't think the code in question only comes into play for asynchronous checkin. It was just higlighted as one occurance where double capture can happen. |
| 11:28 |
pinesol_green |
[evergreen|Jason Stephenson] Forward port 2.9.0 to 2.9.1 db upgrade script. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ea474a9> |
| 11:29 |
csharp |
kmlussier: yeah, I'm asking them to try with the checkbox unchecked, but it still looks like there's some bugaboo lurking there |
| 11:29 |
kmlussier |
Yeah, looking at my notes on bug 902255, I was able to replicate the bug without asynchronous checkin being selected. In testing, the user-friendly error message did appear. |
| 11:29 |
pinesol_green |
Launchpad bug 902255 in Evergreen "possible to double-scan an item during check-in and have it captured by two holds" [Low,Fix released] https://launchpad.net/bugs/902255 |
| 11:31 |
csharp |
kmlussier: your comment #7 there is exactly what was reported to m |
| 11:31 |
csharp |
e |
| 11:31 |
kmlussier |
csharp: Same event number? |
| 11:32 |
csharp |
actually no, our number is 2001 |
| 11:36 |
|
Christineb joined #evergreen |
| 11:38 |
|
afterl joined #evergreen |
| 11:41 |
jwoodard |
the query in record buckets is not friendly |
| 11:41 |
* tsbere |
is curious what query jwoodard is talking about |
| 11:42 |
jwoodard |
the query book in record buckets |
| 11:42 |
jwoodard |
it gives me what I want except the rest of the 359 results |
| 11:43 |
* jwoodard |
needs page 2 |
| 11:43 |
* tsbere |
apparently missed something but has no clue what ;) |
| 11:43 |
kmlussier |
jwoodard: Are you talking about the max results you get in the record bucket? |
| 11:44 |
jwoodard |
kmlussier: yes, I am not being very eloquent this morning |
| 11:44 |
kmlussier |
jwoodard: Check with mmorgan. I think NOBLE changed that hardcoded limit. |
| 11:45 |
* jwoodard |
must know how! |
| 11:45 |
jwoodard |
thanks for the info kmlussier! |
| 11:46 |
kmlussier |
I'm sure I was part of the discussion at the time, but I don't remember where it was changed. |
| 11:46 |
* tsbere |
gets over 2500 results in the staff interface on MVLC's production system |
| 11:46 |
kmlussier |
tsbere: And they all display? |
| 11:46 |
tsbere |
Well, they load over time as I scroll down, but yea |
| 11:46 |
kmlussier |
On a very postive note, I see paging in the query tab for buckets on webby. |
| 11:46 |
tsbere |
I loaded a record bucket with over 2700 entries, actually, and it looks complete |
| 11:46 |
* berick |
was about to say... |
| 11:47 |
kmlussier |
@eightball will webby solve all of our problems? |
| 11:47 |
pinesol_green |
kmlussier: About as likely as pigs flying. |
| 11:47 |
berick |
teehee |
| 11:47 |
Dyrcona |
:) |
| 11:47 |
kmlussier |
Well, eightball is being very pessimistic today |
| 11:47 |
tsbere |
The only issue I see is the # column is a bit wonky as it loads. |
| 11:47 |
berick |
@eightball is eightball too pessimistic |
| 11:47 |
pinesol_green |
berick: NO! |
| 11:47 |
Dyrcona |
Given enough thrust, anything will fly. |
| 11:47 |
berick |
perfect |
| 11:48 |
Dyrcona |
@eightball is eightball too optimistic? |
| 11:48 |
pinesol_green |
Dyrcona: About as likely as pigs flying. |
| 11:48 |
* tsbere |
just realized that, oh hey, the record bucket he loaded is a public bookbag |
| 11:48 |
kmlussier |
So I'm looking at the query tab in xul. When I do a query, I get 8308 hits, but when I scroll down, I only see 100. You're all telling me that the same thing doesn't happen to you? |
| 11:49 |
kmlussier |
No, we're not talking about the bucket itself. It's the query tab where you can add results from a query to the bucket. |
| 11:49 |
* tsbere |
looks, isn't even seeing the query tab, and realizes he may be running a broken client he was playing with last week |
| 11:50 |
tsbere |
Let me log into the normally installed client <_< |
| 11:50 |
kmlussier |
Actually, the tab is called "record query" |
| 11:50 |
kmlussier |
But, I'm sure you would have made that leap if you had seen it. :) |
| 11:50 |
tsbere |
And I have "Bucket View" and....that is it. |
| 11:51 |
* kmlussier |
is puzzled |
| 11:51 |
tsbere |
kmlussier: As I mentioned a moment ago, I was running a client I was playing with the code of. I am logging into our actual distributed client now. |
| 11:55 |
JBoyer |
kmlussier, jwoodard: I'm seeing the same thing here, on 2.9. 100 results to record searches in the bucket interface. |
| 11:55 |
JBoyer |
(out of 1633, that is.) |
| 11:55 |
tsbere |
And I am now seeing that as well. Though I wonder, does offset(100) return "page 2"? |
| 11:56 |
JBoyer |
tsbere: do you mean in the search box? |
| 11:56 |
tsbere |
JBoyer: Yea, though I haven't checked if that is the actual syntax |
| 11:57 |
* tsbere |
is assuming this is queryparser syntax of some kind, but if it isn't then he isn't as sure |
| 11:57 |
JBoyer |
Well... the results are different, it's possible. |
| 11:57 |
JBoyer |
Oh! that does do it. |
| 11:58 |
tsbere |
I assume 200 would be page 3 and so on |
| 11:58 |
tsbere |
In that case |
| 11:58 |
JBoyer |
jwoodard: there you go. If you need to go past the first page, add an offset(X00) to your search, increasing X for each page. |
| 12:00 |
JBoyer |
That's not a "fix" exactly, but it will get you going. (Sounds like the web client is proper fixed, so hurray!) |
| 12:00 |
tsbere |
kmlussier: Fun with QP syntax, apparently. :D |
| 12:00 |
* tsbere |
goes to lunch |
| 12:01 |
bshum |
"fun" and "QP" does not compute in the same sentence for me... |
| 12:01 |
kmlussier |
Yeah, I'm still a fan of increasing the hardcoded limits, particularly in cases where library staff is manipulating those buckets. |
| 12:02 |
kmlussier |
bshum: Where's your sense of adventure? |
| 12:03 |
|
ericar_ joined #evergreen |
| 12:04 |
* jwoodard |
is back |
| 12:04 |
* jwoodard |
missed a long discussion |
| 12:05 |
jwoodard |
thanks all! tsbere++ JBoyer++ |
| 12:05 |
JBoyer |
kmlussier: to change the limit, edit line 885 of .../server/cat/record_buckets.js and change 100 to whatever. Here's master: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/xul/staff_client/server/cat/record_buckets.js;h=77b740809124e6c049af2f383649b2c980c574c3;hb=HEAD#l885 |
| 12:05 |
JBoyer |
Might need an apache restart? I don't know. |
| 12:05 |
bshum |
Client restart probably |
| 12:05 |
bshum |
To grab fresh files |
| 12:06 |
JBoyer |
Oh, yeah. I suppose Apache may notice the edit times, the client won't necessarily ask for them again though. |
| 12:07 |
bshum |
JBoyer++ |
| 12:07 |
* bshum |
fades back into the mists... |
| 12:07 |
JBoyer |
This is all still just Queryg stuff though, Depending on what kmlussier meant by "manipulating," you should always be able to load the full /contents/ of a bucket, so far as I know. |
| 12:10 |
kmlussier |
JBoyer: By manipulating, I meant when library staff are doing the queries to add titles to the record. Adding the offset(x) to the query is something I have no problem doing, but I wouldn't expect them to do it. |
| 12:10 |
kmlussier |
JBoyer++ |
| 12:10 |
kmlussier |
Sorry, that should be "add titles to the record bucket." |
| 12:16 |
jwoodard |
I am putting together a "how-to" manual for batch editing with record buckets |
| 12:16 |
jwoodard |
I know others will want to know how to get to "page 2". |
| 12:17 |
|
berick joined #evergreen |
| 12:18 |
mmorgan |
jwoodard: Late to chime in, but we did raise the limit of records retrieved for record buckets to 1000. /openils/var/web/xul/server/cat/record_buckets.js Line 85 |
| 12:18 |
mmorgan |
Well, maybe not so late after all :) |
| 12:19 |
mmorgan |
And sorry, that's line 885 |
| 12:19 |
|
jihpringle joined #evergreen |
| 12:21 |
|
bmills joined #evergreen |
| 12:35 |
|
book` joined #evergreen |
| 12:35 |
|
krvmga joined #evergreen |
| 12:43 |
Dyrcona |
hmmm... "not something we can merge" must be a typo. |
| 12:45 |
Dyrcona |
yep. |
| 12:45 |
Dyrcona |
missing an 's' in the branch name. |
| 12:50 |
Dyrcona |
Oh, bummer. Guess I should merge fewer branches at a time. |
| 12:55 |
mrpeters |
hey all, i know http://git.evergreen-ils.org/?p=contrib/equinox.git;a=summary is a bit dated, but does the drone count refer to any specific number in the opensrf config XML's? I'm thinking it may be max children, but want to confirm |
| 12:55 |
Dyrcona |
Hmm. I get a conflict with merging working/user/gmcharlt/lp1508477-better-webstaff-hotkeys |
| 12:56 |
gmcharlt |
Dyrcona: would you like me to rebase quick-like? |
| 12:56 |
Dyrcona |
gmcharlt: That would be helpful. I'm not sure if I the hotkeys branch is meant to delete lines from bower.json. |
| 12:57 |
Dyrcona |
I wonder if another branch adds the lines though... I'm merging sprint2-sprint3 also.... |
| 12:58 |
Dyrcona |
Ah! I think I solved it. I do need to keep the "extra" lines. |
| 12:58 |
mrpeters |
disregard quesiton from above -- after looking at it, i see it is using XML::LibXML to parse the opensrf*.xml files |
| 12:59 |
gmcharlt |
Dyrcona: great; still want a rebase? |
| 12:59 |
Dyrcona |
gmcharlt: I don't think it is necessary, unless you want to rebase with the sprint2-sprint3 branch. |
| 13:00 |
gmcharlt |
OK, I'll leave it be, but more than happy to assist as you continue dealing with sprint2-sprint3 |
| 13:03 |
mrpeters |
gmcharlt: figure you are as good as anyone to ask -- i have a patch to fix a typo in the readme for eg-stats montioring tool, as well as some filtering rules that seem to work better with rsyslog (via JBoyer) -- who best to send a patch file to so that can be fixed in the contrib/equinox.git branch? |
| 13:04 |
gmcharlt |
mrpeters: send it my way |
| 13:04 |
mrpeters |
gmcharlt: will do. thank you! |
| 13:04 |
mrpeters |
may be later this afternoon, but ill get it to you. thanks! |
| 13:04 |
gmcharlt |
thanks |
| 13:05 |
mrpeters |
thanks to you all for offering up the tools still! |
| 13:08 |
Dyrcona |
"Curiouser and curiouser," said Alice. |
| 13:08 |
* Dyrcona |
thinks I'm merging way too many branches at once. |
| 13:09 |
Dyrcona |
I just got conflict markers around a line that log -p says didn't exist before I merged the branch that caused the conflict, but the conflict markers suggested otherwise. |
| 13:09 |
kmlussier |
Dyrcona: If it's too many, I'm okay with not looking at them. |
| 13:09 |
kmlussier |
Dyrcona: At this point, I'm mostly interested in the patron editor branch. |
| 13:09 |
Dyrcona |
It's one of the vlewis branches that has me scratching my head. |
| 13:12 |
Dyrcona |
Never mind.... I'm not paying enough attention to the logs.... |
| 13:12 |
Dyrcona |
When I resolved the conflict, the file ended up not counting as modified. |
| 13:13 |
* Dyrcona |
pops through the keyhole. |
| 13:14 |
|
vlewis joined #evergreen |
| 13:15 |
kmlussier |
gmcharlt: If I find that the sprint2-sprint3 branch work well on Dyrcona's server, would it be a good time to merge it? I would love to get all of that code into core, especially the sprint 2 fixes. |
| 13:16 |
Dyrcona |
kmlussier: I noticed that gmcharlt updated it yesterday, and that was where my new conflict came from, so it may not be ready. |
| 13:17 |
gmcharlt |
kmlussier: sure, though I anticipate having more sprint2 fixes done this week; to set a single point for the merge, I'll be done by Friday |
| 13:17 |
gmcharlt |
after that, it should just be sprint3 changes |
| 13:18 |
kmlussier |
gmcharlt: OK, that's a good timeframe. I probably won't get to look at it until then anyway. |
| 13:18 |
kmlussier |
I imagine it won't take me too long to look at since I've verified many of the bug fixes work on webby. |
| 13:19 |
kmlussier |
Dyrcona: You mentioned yesterday that you have a script that allows you to do cherry pick a lot of commits at once? |
| 13:20 |
Dyrcona |
Yes. |
| 13:20 |
Dyrcona |
https://gist.github.com/Dyrcona/4629200 |
| 13:20 |
Dyrcona |
Install it in ~/bin/git-quickpick |
| 13:21 |
Dyrcona |
then, you get a quickpick command in git. |
| 13:21 |
Dyrcona |
git quick someremote/somebranch |
| 13:21 |
Dyrcona |
gah... |
| 13:21 |
Dyrcona |
git quickpick someremote/somebranch |
| 13:21 |
Dyrcona |
I usually use merge on my development branches. |
| 13:21 |
kmlussier |
Dyrcona++ |
| 13:22 |
kmlussier |
quickpick makes me feel like I'm playing the lottery. |
| 13:23 |
Dyrcona |
yeah, the name was chosen back when there was a then record jackpot of $500 million or so for the Powerball. |
| 13:24 |
csharp |
@who will win the Evergreen Powerball? |
| 13:24 |
pinesol_green |
RBecker will win the Evergreen Powerball. |
| 13:24 |
Dyrcona |
It's nice for signing off: git quickpick -s working/user/gmcharlt/the-greatest-patch-ever |
| 13:24 |
gmcharlt |
no pressure! |
| 13:24 |
gmcharlt |
;) |
| 13:24 |
Dyrcona |
:) |
| 13:24 |
berick |
dbwells: for bug 1468422, do you anticipate adding the final auth-proxy changes soon? if not, I can take a look at it. I'd love to have it cleaned up and merge-able before next week's 2.10 feature slush date. |
| 13:24 |
pinesol_green |
Launchpad bug 1468422 in Evergreen "Improve Password Management and Authentication" [Undecided,New] https://launchpad.net/bugs/1468422 |
| 13:24 |
kmlussier |
Does the-greatest-patch-ever have anything to do with winning the lottery? |
| 13:24 |
Dyrcona |
It might. |
| 13:25 |
kmlussier |
Because that would indeed be great. Almost as good as a patch that allows Evergreen to serve coffee. |
| 13:26 |
|
mdriscoll joined #evergreen |
| 13:28 |
Dyrcona |
kmlussier: I think I'll use this branch for a few days. If gmcharlt pushes changes to the sprint2-sprint3 branch, I'll pull them in and install them. |
| 13:28 |
dbwells |
berick: I'll take a poke right now, shouldn't take long. I did encounter an unrelated issue, though, which maybe you can look at. |
| 13:28 |
kmlussier |
Dyrcona: Sounds good. Thanks! |
| 13:28 |
kmlussier |
Dyrcona++ |
| 13:28 |
Dyrcona |
Now, I just have to run db upgrade scripts and install the code. ;) |
| 13:29 |
dbwells |
berick: If you try to login with a username which doesn't exist, you get an unhandled error. This is new behavior. |
| 13:29 |
berick |
dbwells: ah, ok, i'll take a look |
| 13:29 |
berick |
thanks |
| 13:29 |
dbwells |
berick: I comes from the fact that the code tries use the encrypted password as the seed, and if the user doesn't exist, there obviously isn't one to use. |
| 13:30 |
berick |
ok, should be a simple fix |
| 13:30 |
dbwells |
berick: I'm thinking in that case we need to make something up just so the 'complete' call has something to find on the othe side. Sound like you got it :) |
| 13:31 |
berick |
dbwells: yeah, the existing code returns an "x" when no user is found. i'll just recreate that |
| 13:31 |
berick |
as the seed, i mean |
| 13:33 |
berick |
ah, ok, it's trying to do that, but failing before it gets there |
| 13:33 |
|
collum joined #evergreen |
| 13:56 |
|
ericar_ joined #evergreen |
| 13:57 |
|
hopkinsju joined #evergreen |
| 13:57 |
|
dluch joined #evergreen |
| 13:57 |
|
Bmagic joined #evergreen |
| 14:18 |
berick |
dbwells: fix pushed |
| 14:18 |
csharp |
most of our slowest queries at the moment (with the db server under no duress) are what is described in bug 1514549 |
| 14:18 |
dbwells |
berick++ |
| 14:18 |
pinesol_green |
Launchpad bug 1514549 in Evergreen "Pub date sorting/filtering causes slow OPAC search" [Undecided,New] https://launchpad.net/bugs/1514549 |
| 14:19 |
csharp |
I have *not* applied jeffdavis 's fix for bug 1499086 yet |
| 14:19 |
pinesol_green |
Launchpad bug 1499086 in Evergreen 2.9 "Slowness/timeout on loading bookbags in OPAC" [Medium,Triaged] https://launchpad.net/bugs/1499086 |
| 14:20 |
* csharp |
nervously waits for 3:00/3:30 for the DB problems to begin again |
| 14:21 |
csharp |
our PG 2.9 adventures are continuing - I guess I haven't said that explicitly |
| 14:21 |
csharp |
sorry PG 9.4/EG 2.9.1 |
| 14:22 |
csharp |
pgbadger++ |
| 14:22 |
|
bmills joined #evergreen |
| 14:34 |
jeffdavis |
csharp: your slowness issues show up at a particular time of day? |
| 14:36 |
|
ericar_ joined #evergreen |
| 14:38 |
csharp |
jeffdavis: well, after we tweaked join_collapse_limit and miker tweaked one of the OU functions, we were good, but yesterday at around 3:30 DB queries started piling up and slowing us down to a crawl |
| 14:38 |
csharp |
Monday and Tuesday afternoons are usually busy in PINES |
| 14:38 |
jeffdavis |
:( |
| 14:39 |
csharp |
jeffdavis: are you seeing any other problems than what you reported in the bookbag slowness bug report? |
| 14:39 |
jeffdavis |
no, db has been fine for us otherwise |
| 14:39 |
csharp |
good to know |
| 14:40 |
jeffdavis |
at one point we had an issue with autosuggest queries bogging down the system, which we resolved by (a) turning off autosuggest and (b) doing some vacuuming IIRC ... but I imagine that's not what you're seeing |
| 14:40 |
jeffdavis |
and it's not 9.4 specific in any case |
| 14:41 |
jeffdavis |
I kinda wish we had had more problems with the PG upgrade so I'd have something helpful to suggest :/ |
| 14:42 |
csharp |
jeffdavis: :-) thanks |
| 14:42 |
csharp |
that's a great way to look at what we're doing - finding problems so others don't have to |
| 14:43 |
csharp |
we're going to give it another week, then roll back to 9.3 if we're still seeing this |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:08 |
csharp |
hmm: SELECT * FROM unapi.bre( '4702469', 'marcxml', 'record', '', 'PINES', '0', 'acn=>5,acp=>5', NULL, NULL, NULL ) AS "unapi.bre" ; |
| 15:09 |
csharp |
ERROR: malformed array literal: "" at character 58 DETAIL: Array value must start with "{" or dimension information. |
| 15:09 |
csharp |
seeing lots of that in the logs |
| 15:11 |
berick |
csharp: hmm, the empty string after record should probably be '{}' (or mabye NULL). |
| 15:11 |
csharp |
looks like that's a blank "includes" - not sure where that happens on the front end |
| 15:11 |
berick |
not sure where that would come from... |
| 15:11 |
csharp |
includes text[] is the field that's blank there |
| 15:11 |
JBoyer |
csharp: I think the unapi stuff is used a lot in the TPAC, do you know if there have been any customizations done with that? I'm seeing mostly '{holdings_xml,bmp,mra,acp,acnp,acns}' where you've got that blank string |
| 15:12 |
csharp |
hmm - yeah we definitely have customizations... |
| 15:12 |
JBoyer |
Well, I suppose that's a silly question, 90% of us probably do. :) I guess I meant specifically around record detail pages, maybe? I can't remember where unapi calls are used most. |
| 15:13 |
csharp |
hmm - no entry in activity.log for that threadtrace :-/ |
| 15:13 |
csharp |
JBoyer: yeah, I know we've done customizations there |
| 15:15 |
berick |
csharp: check for first occurrence in osrfsys.x.log |
| 15:15 |
berick |
tpac and some other services log little to nothing in the activity logs |
| 15:16 |
csharp |
CALL: open-ils.cstore open-ils.cstore.json_query {"from":["unapi.bre","2523067","marcxml","record","","PINES","0","acn=>5,acp=>5",null,null,null]} |
| 15:21 |
JBoyer |
I think something's up with that. We've had unapi.bre called over 125K times today, never once with an empty array. |
| 15:22 |
JBoyer |
(meaning "{}", there's always something) |
| 15:24 |
csharp |
I'll investigate |
| 15:24 |
csharp |
pretty certain it's not related to slowness issues (no such queries in pgbadger's slow query list, for instance) |
| 15:24 |
csharp |
btw, so far so good |
| 15:25 |
csharp |
and I hope it's not because people are on frakking standalone |
| 15:25 |
* csharp |
has been re-watching BSG |
| 15:28 |
Bmagic |
csharp: we just upgraded to 9.3 last week. We are seeing long running queries more and more. metabib.suggest_browse_entries seems to be the most lengthy. After the upgrade, we preformed an analyze and vacuum on the whole database |
| 15:29 |
Bmagic |
Those queries were taking so long that it clobbered the db server. Things are better now, but those queries are still taking a long time to return. The saga continues |
| 15:30 |
csharp |
hmm |
| 15:30 |
csharp |
Bmagic: have you done any explain analyzes on the core_queries? |
| 15:31 |
csharp |
Bmagic: is that autosuggest, btw? |
| 15:31 |
csharp |
(we don't have that enabled here) |
| 15:31 |
csharp |
jeffdavis was mentioning slow autosuggest on 9.4 |
| 15:31 |
Bmagic |
yes, hopkinsju did - I haven't seen those results yet |
| 15:32 |
Bmagic |
csharp: I think* it's autosuggest - however, in practice, I get results in the autosuggest instantly so I wouldn't think it would be that |
| 15:36 |
jeffdavis |
Bmagic: with autosuggest, the problem for us would be slowly-typed queries - e.g. searching for "canada" triggers separate queries for "c", "ca", "can", "cana" - so by the time you finish typing, you probably have search terms that return results quickly, and never realize that the terribly slow ones are still running in the background |
| 15:36 |
Bmagic |
queries against metabib.suggest_browse_entries can only be autosuggest? |
| 15:36 |
Bmagic |
jeffdavis: exactly what I am seeing! |
| 15:36 |
Bmagic |
did you solve this? |
| 15:37 |
jeffdavis |
Sort of. First step was to turn autosuggest off (on the argument that it's also bad for screen readers etc). Afterwards we did the vacuum etc, like you, and found that it helped a lot. But we left autosuggest turned off anyway. |
| 15:38 |
Bmagic |
it seems like the javascript code should wait for the user to pause before it fires the query |
| 15:38 |
Bmagic |
or make that db function work better? |
| 15:38 |
jeffdavis |
or don't fire the query until you have at least X characters |
| 15:39 |
jeffdavis |
(non-exclusive or there :) |
| 15:45 |
|
dbwells joined #evergreen |
| 15:45 |
Bmagic |
jeffdavis: I wonder why we didn't have this problem on 9.2 ? |
| 15:47 |
jeffdavis |
We figured it had more to do with needing to vacuum after the PG+EG upgrade. |
| 15:48 |
jeffdavis |
Hard to say, though. At least I don't think we had any definitive evidence of our conclusion. |
| 15:51 |
csharp |
more info on that unapi.bre error - all I've seen and tested appear to be kid's titles, so the KPAC is suspect |
| 15:51 |
csharp |
@blame kpac |
| 15:51 |
pinesol_green |
csharp: kpac forgot to give the gerbils their chocolate-frosted sugar bombs |
| 15:58 |
dbwells |
berick: Got the validate bits in place for AuthProxy.pm. I pushed it (plus your latest fix) out to production here locally, and am going to let it chill for a bit before pushing back to the collab branch. At this point in the day, probably going to be tomorrow. |
| 15:59 |
Bmagic |
jeffdavis: now that I am looking at config.tt2 I dont see where to turn off autosuggest. I would have expected to see the setting there. where is use_autosuggest.enabled ? Should I just set that variable in config.tt2? |
| 16:02 |
kmlussier |
Bmagic: Maybe a global flag? |
| 16:02 |
dbwells |
Bmagic: It's a Global Flag |
| 16:02 |
kmlussier |
I could be misremembering |
| 16:02 |
kmlussier |
Ah, my memory is still good. Thanks dbwells! |
| 16:02 |
Bmagic |
ah |
| 16:02 |
Bmagic |
ty |
| 16:04 |
berick |
dbwells++ |
| 16:04 |
kmlussier |
In the web client's copy editor, some fields have a green background and others don't. Does that green background have a particular meaning? |
| 16:09 |
|
jlitrell joined #evergreen |
| 16:11 |
kmlussier |
OK, I see, it's when a value is successfully selected. |
| 16:12 |
kmlussier |
And when I pull it up, the fields that have a default value immediately show the green background color. |
| 16:12 |
csharp |
why is it that when you *want* to see major errors, you don't see them! |
| 16:18 |
kmlussier |
In the current client, the green background only comes into play when you successfully select a new value. It doesn't display for the fields that have default values when you first retrieve the editor. That behavior makes more sense to me, maybe because I'm used to it. |
| 16:19 |
* kmlussier |
feels like her ramblings about background color are inconsequential when compared to csharp's lack of major errors. :) |
| 16:19 |
tsbere |
csharp: Quantum physics: When someone who has a clue about the problem is observing the system the problem won't occur. ;) |
| 16:20 |
Bmagic |
Did anything happen to autosuggest between 2.8.2 and 2.9.1? DB function or javascript code? We are seeing db CPU loads doubled on average. suggeset browse is the offender |
| 16:23 |
|
vlewis_ joined #evergreen |
| 16:29 |
mrpeters |
anyone seen errors similar to osrferror.log:2016-01-26 15:46:45 brick03-head open-ils.cstore: [ERR :20771:oils_sql.c:5797:145376769320225174] open-ils.cstore: Error with query [SELECT * FROM unapi.bre( '4458758', 'marcxml', 'record', '', 'PINES', '0', 'acn=>5,acp=>5', NULL, NULL, NULL ) AS "unapi.bre" ;]: 3484946 3484946: ERROR: malformed array literal: ""#012LINE 1: ...* FROM unapi.bre( '4458758', 'marcxml', 'record', '', 'PIN |
| 16:30 |
mrpeters |
running the raw SQL gives a little more information (http://pastebin.com/dSwkNwQ1) but i'm not sure what that empty field is |
| 16:30 |
mrpeters |
all is well if i {} inside those quotes |
| 16:33 |
tsbere |
mrpeters: Looks like something that should be spitting out NULL into the query is instead providing an empty string to me... |
| 16:33 |
tsbere |
But I don't know where it is coming from in EG |
| 16:33 |
mrpeters |
tsbere: yeah, thats where i was kind of going with this -- is it a problem with the MARC, or a problem with Evergreen |
| 16:34 |
Bmagic |
none of my logs (2.9.1) contain those errors in the last 7 days |
| 16:34 |
mrpeters |
pretty sure it was a kpac hold |
| 16:34 |
Bmagic |
oh, we don't use kpac |
| 16:34 |
tsbere |
mrpeters: The missing/bad param is "includes" which looks like "include various other details like mra or holdings info" |
| 16:35 |
mrpeters |
tsbere: awesome -- thanks we were wondering what was expected in that spot |
| 16:35 |
mrpeters |
would hold placement on that bre.id trigger a query against unapi.bre like that? |
| 16:35 |
tsbere |
May be that something is asking for unapi stuff and doesn't care about the extra pieces at all, but the wrong "nothing" value is making it to the DB... |
| 16:37 |
tsbere |
mrpeters: Ooooh, looks like it could be A/T related, if unapi_bre is being called with bad args? |
| 16:37 |
mrpeters |
hmm that is a thought |
| 16:38 |
tsbere |
mrpeters: Specifically, if the "flesh" arg is bad |
| 16:38 |
mrpeters |
it definetly is centered around placing a hold in the examples i am looking at |
| 16:38 |
mrpeters |
SELECT * FROM unapi.bre( '4458758', 'marcxml', 'record', '{holdings_xml,mra,acp,acnp,acns,bmp,cbs}', 'PINES', '0', 'acn=>5,acp=>5', NULL, NULL, '46' ) AS "unapi.bre" ; |
| 16:38 |
mrpeters |
doesn't that look like the proper query? |
| 16:39 |
tsbere |
Could be, at least looks better |
| 16:39 |
mrpeters |
yeah...so eventually that shows up in the pg logs |
| 16:39 |
|
afterl left #evergreen |
| 16:46 |
tsbere |
mrpeters: Could someone have been working with A/T templates and gotten something wrong? |
| 16:46 |
mrpeters |
i dont think so, but i will ask |
| 16:46 |
* tsbere |
can't find any obvious "KPac does something that TPac doesn't" relating to that kind of call |
| 16:46 |
tsbere |
Looks like KPac just kindof inherits the TPac methods for that kind of thing, really... |
| 16:51 |
mrpeters |
I'm just not sure if its hold related or not -- we saw the error at 15:46:45, pg tried to run the bad query obviously at the same time, and then 1 second later runs the right query |
| 16:51 |
mrpeters |
pg.15.log:Jan 26 15:46:56 db01 postgres[57901]: [902-1] db=evergreen,user=evergreen LOG: duration: 102.157 ms statement: SELECT * FROM unapi.bre( '4458758', 'marcxml', 'record', '{holdings_xml,mra,acp,acnp,acns,bmp,cbs}', 'PINES', '0', 'acn=>5,acp=>5', NULL, NULL, '46' ) AS "unapi.bre" ; |
| 16:51 |
mrpeters |
pg.15.log:Jan 26 15:47:00 db01 postgres[55456]: [1278-1] db=evergreen,user=evergreen LOG: duration: 0.241 ms statement: SELECT "bpbcm".id, "bpbcm".peer_type, "bpbcm".peer_record, "bpbcm".target_copy FROM biblio.peer_bib_copy_map AS "bpbcm" WHERE "bpbcm".peer_record = '4458758'; |
| 16:51 |
mrpeters |
err sorry wrong line |
| 16:51 |
mrpeters |
pg.15.log:Jan 26 15:47:00 db01 postgres[54599]: [3859-1] db=evergreen,user=evergreen LOG: duration: 93.514 ms statement: SELECT * FROM unapi.bre( '4458758', 'marcxml', 'record', '{holdings_xml,bmp,mra,acp,acnp,acns}', 'PINES', '0', 'acn=>5,acp=>5', NULL, NULL, NULL ) AS "unapi.bre" ; |
| 16:51 |
mrpeters |
so 4 seconds later, actually -- but it eventually figures out the right query to make |
| 17:05 |
|
mdriscoll left #evergreen |
| 17:09 |
|
mmorgan joined #evergreen |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
|
mllewellyn left #evergreen |
