| Time |
Nick |
Message |
| 00:39 |
|
ssieb joined #evergreen |
| 01:32 |
|
gsams joined #evergreen |
| 02:10 |
|
gsams joined #evergreen |
| 02:39 |
|
gsams joined #evergreen |
| 02:42 |
|
gsams joined #evergreen |
| 03:33 |
|
remingtron joined #evergreen |
| 03:33 |
|
dbwells joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:10 |
bshum |
Thr |
| 07:10 |
bshum |
Oops heh |
| 07:14 |
bshum |
The new Quasseldroid version is so pretty. I might just have to switch back for this... |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:41 |
|
kmlussier joined #evergreen |
| 08:42 |
|
rlefaive_ joined #evergreen |
| 08:53 |
kmlussier |
Happy Friday #evergreen! |
| 08:53 |
kmlussier |
@coffee [someone] |
| 08:53 |
* pinesol_green |
brews and pours a cup of Kenya Ndiara, and sends it sliding down the bar to sard |
| 08:53 |
kmlussier |
@tea [someone] |
| 08:53 |
* pinesol_green |
brews and pours a pot of Golden Orchid, and sends it sliding down the bar to berick (http://ratetea.com/tea/whispering-pines/golden-orchid/7244/) |
| 09:00 |
krvmga |
kmlussier++ |
| 09:08 |
* csharp |
decides to add auditor functions to pretty much any acq table that an end user can touch |
| 09:08 |
csharp |
hopefully preventing me having to ask questions like "did you change the name of the PO after you activated it?" |
| 09:12 |
* rhamby |
resists commenting on what questions csharp will then have to ask |
| 09:18 |
|
yboston joined #evergreen |
| 09:24 |
csharp |
huh - apparently either I already added it or it's already doing that by default |
| 09:25 |
csharp |
in any case, I no longer require an answer from the end user |
| 09:25 |
csharp |
(the answer to my question btw was "yes" ;-) ) |
| 09:25 |
csharp |
we're seeing an intermittent issue where invoices coming back from the vendor are not linking back to the PO |
| 09:26 |
csharp |
I believe I've tracked it down to the way the library is naming the POs |
| 09:26 |
|
Dyrcona joined #evergreen |
| 09:27 |
csharp |
for the one that worked (in my small sample), they didn't name it initially, so the "po_name/li_id" formatting in the EDI worked as expected |
| 09:27 |
kmlussier |
It looks like auditor tables are there by default for invoices, but not for POs. I can see how that would be useful. |
| 09:28 |
csharp |
the ones with custom names like "STEAMBK 9-6 FY17 pt2" are not working (provider is Ingram, btw) |
| 09:28 |
Dyrcona |
csharp: Spaces in PO names cause problems. |
| 09:28 |
kmlussier |
Dyrcona: Didn't you fix that? |
| 09:28 |
Dyrcona |
I believe there was a patch, but not sure what release (if any) it made it into. |
| 09:29 |
Dyrcona |
I think berick actually fixed it. |
| 09:29 |
csharp |
Dyrcona: ah, that was actually my working theory |
| 09:29 |
* Dyrcona |
dumps data frequently 'cause the drive is full. |
| 09:29 |
kmlussier |
bug 1519465 |
| 09:29 |
pinesol_green |
Launchpad bug 1519465 in Evergreen 2.9 "Purchase Orders with spaces in the name cause problems with EDI processing" [Medium,Fix released] https://launchpad.net/bugs/1519465 |
| 09:29 |
csharp |
and I was thrown off by the fact that both POs have names with spaces, but they *added* the name to the working one after it processed |
| 09:30 |
csharp |
Dyrcona++ kmlussier++ # thanks! |
| 09:30 |
csharp |
our acq person had searched for bugs, but we hadn't isolated the problem to spaces in the PO name until just now |
| 09:30 |
Dyrcona |
Guess I did fix it.... |
| 09:31 |
* Dyrcona |
is too busy to remember much beyond yesterday. |
| 09:31 |
* csharp |
runs off to apply the patch to our system |
| 09:31 |
kmlussier |
My brain is full with useful facts about LP bugs leaving little room for what might be more useful information. |
| 09:31 |
csharp |
kmlussier: thanks for that! |
| 09:32 |
csharp |
I'm trying to get better about tracking bugs as they happen and not recreating the wheel all the time |
| 09:32 |
csharp |
complicating this issue further is that the predecessor to the end user with the problem was just working around it without reporting it to us :-/ |
| 09:33 |
|
maryj joined #evergreen |
| 09:35 |
kmlussier |
Meant to say 'useless' facts about LP bugs. Need coffee. |
| 09:38 |
|
maryj joined #evergreen |
| 09:39 |
mmorgan |
@coffee kmlussier |
| 09:39 |
* pinesol_green |
brews and pours a cup of Kenya Gethembwini, and sends it sliding down the bar to kmlussier |
| 09:51 |
|
mmorgan1 joined #evergreen |
| 09:56 |
csharp |
@praise Dyrcona for fixing that bug |
| 09:56 |
* pinesol_green |
the upgrade came off brilliantly, and it's all because of Dyrcona for fixing that bug |
| 09:56 |
csharp |
@blame PINES for not upgrading to point releases |
| 09:56 |
pinesol_green |
csharp: PINES forgot to give the gerbils their chocolate-frosted sugar bombs for not upgrading to point releases |
| 09:57 |
* tsbere |
stares at a pile of checked out copies with no open circulations and wonders "WTF?" |
| 09:59 |
Dyrcona |
tsbere: Comcat/NCIPServer? |
| 10:00 |
csharp |
tsbere: Wow That's Fantastic? |
| 10:01 |
tsbere |
Dyrcona: Spread out over....pretty much the entire time MVLC has been on Evergreen. In a few cases it looks like some circs were wiped out to aged_circulation while the copy was flagged as "Checked Out" |
| 10:01 |
Dyrcona |
Fun! |
| 10:02 |
* tsbere |
suspects that was "patrons deleted before some protections were put in for patrons with open circs" or similar... |
| 10:02 |
Dyrcona |
Could be. |
| 10:02 |
Dyrcona |
On an unrelated note: Wow! It takes a long time to compile libcrypto from libreSSL. |
| 10:03 |
* Dyrcona |
is patching his OpenBSD router after upgrading. While stuff comiles, I'm looking into SQL scripts to run on Tuesday. |
| 10:04 |
Dyrcona |
We've come up with a schedule for running random DB changes that staff request. The latest one has a few issues related to patron barcodes, etc. |
| 10:05 |
|
mmorgan joined #evergreen |
| 10:13 |
|
rlefaive joined #evergreen |
| 10:17 |
csharp |
tsbere: didn't you say you upped cstore timeouts on your utility server to something crazy to accommodate long-running A/T events? |
| 10:17 |
csharp |
or was it Dyrcona who told me that? |
| 10:18 |
Dyrcona |
I might have said that, though I don't think it was something crazy. |
| 10:18 |
csharp |
our invoice/PO printing is timing out so it stalls the A/T events at "reacting" |
| 10:19 |
tsbere |
csharp: I can check those values if you want |
| 10:19 |
csharp |
"something crazy" was like "120 seconds" or somesuch |
| 10:19 |
csharp |
tsbere: yes please :-) |
| 10:19 |
Dyrcona |
Also, which timeouts? ;) |
| 10:19 |
csharp |
cstore, sorry |
| 10:20 |
csharp |
basically, the event is processing, then opensrf checks after 6 seconds (default timeout) and it's not done, so it assumes it died and moves on |
| 10:20 |
tsbere |
csharp: We have a <utility.host.name><apps><open-ils.cstore><keepalive> block in our opensrf.xml set to 120 |
| 10:20 |
csharp |
tsbere: perfect - that's what I remembered |
| 10:20 |
csharp |
thanks |
| 10:21 |
Dyrcona |
That sounds familiar. ;) |
| 10:21 |
* csharp |
tries to fix ALL THE ACQ THINGS! |
| 10:21 |
Dyrcona |
I was thinking of the drop a connected session after x seconds timeout. |
| 10:26 |
|
Dyrcona joined #evergreen |
| 10:27 |
Dyrcona |
Heh. Rebooted the router. :) |
| 10:29 |
berick |
csharp: to be clear, keepalive only comes into play if a drone is completely idle for $keepalive seconds. it's not working on any tasks and there's no communcation from the client. |
| 10:29 |
berick |
a long-running task is not affected by keepalive |
| 10:30 |
berick |
reqiring a 120 second keepalive suggests a serious logic error in the code |
| 10:32 |
berick |
(and could very quickly lead to cstore exhaustion) |
| 10:32 |
tsbere |
berick: A/T "start CStore transaction, get data, spend 68 seconds working with data, go back to CStore and CStore has decided the caller crashed/forgot to close the transaction at 6 seconds of waiting..." |
| 10:32 |
tsbere |
(at least that is kind of thing MVLC was seeing) |
| 10:34 |
berick |
then A/T needs to be taught to exit the transaction during that long window |
| 10:34 |
berick |
A/T is pretty aggressive about not leaving xacts open. it does a lot of begin/commits |
| 10:34 |
berick |
it may just need more |
| 10:34 |
csharp |
actually, changing that isn't going to help me anyway, since it's the apache/app servers, not utility, where PO printing happens |
| 10:36 |
csharp |
and what tsbere described is what we're seeing |
| 10:36 |
tsbere |
berick: To be honest, the first time we figured out what was going on the A/T "delay" point was 6 to 7 seconds. Exceptionally large A/T groupings seem to make it worse when using global A/T templates, though. |
| 10:37 |
csharp |
what needs to happen in my mind is that it just needs to be asynchronous, period |
| 10:37 |
csharp |
no one will complain if they don't get their printed PO immediately as long as they get it |
| 10:37 |
berick |
tsbere: *nod* |
| 10:38 |
csharp |
and right now they can't get it, which leaves us with the nightmare of trying to make reports do it :-( |
| 10:43 |
berick |
ugh, the A/T reactor code is littered with code that starts transactions without closing them. |
| 10:43 |
berick |
that's more of a cstore exhaustion problem than an keepalive problem, but still |
| 10:45 |
* berick |
opens bug |
| 10:53 |
berick |
hm, i forgot about the DESTROY, which does call ->disconnect |
| 10:53 |
* berick |
wonders how aggressively Perl does that |
| 10:54 |
berick |
implicit_rollbacks-- |
| 10:59 |
|
Christineb joined #evergreen |
| 11:09 |
berick |
csharp: the PO's the won't print, their really big? or is it pretty much any PO? |
| 11:29 |
csharp |
berick: it's just the big ones |
| 11:29 |
csharp |
" |
| 11:29 |
csharp |
"big" = 313 lineitems with copies |
| 11:29 |
csharp |
the PO template was modified to include copy/fund info |
| 11:30 |
csharp |
so some of it is "our fault" but the libraries say they need it on there for auditing purposes |
| 11:30 |
csharp |
and "do smaller orders to accommodate this specific limitation" is met with a firm no |
| 11:33 |
csharp |
we've been going back and forth about this issue for nearly a year |
| 11:33 |
csharp |
(internally) |
| 11:36 |
berick |
if it's stuck in 'reacting' then it's able to fetch all of the data, env data anyway. so, sounds like just building the template is taking too long. |
| 11:37 |
berick |
template building itself should not be in a transaction, though. does not appear to be. |
| 11:40 |
berick |
csharp: have you figured out where in the process it's dying? (if not, maybe a hackaway project) |
| 11:40 |
csharp |
berick: not quite - I'll look - and I agree about the hackaway idea (we did some of this last year) |
| 11:40 |
csharp |
if I can't nail it down by then |
| 11:41 |
* csharp |
adds to hackaway agenda page |
| 11:45 |
Dyrcona |
Ah. I just remembered that I'm supposed to look into changing our courtesy notice email template.... |
| 11:52 |
csharp |
berick: it dies during open-ils.cstore.direct.action_trigger.event_output.create <new object> |
| 11:53 |
csharp |
so it grabs all the data from lineitems, lineitem details, lineitem attrs, lineitem notes, etc. successfully |
| 11:54 |
|
brahmina joined #evergreen |
| 11:54 |
berick |
csharp: ok, how long does the cstore call take to create the output? |
| 11:57 |
tsbere |
berick: From the sidelines I suspect that the transaction was still open from fetching everything while it was correlating and building the output(s) - mainly because I seem to recall that is what it looked like to us when we had some issues. The error on making the outputs would be the transaction closed in the middle. |
| 11:57 |
Dyrcona |
So, I've been asked to change "due in 2 days" to "due on Day of week name, Month name, day of month, year." |
| 11:58 |
Dyrcona |
This is gonna require some macro magic to convert circ.due_date to a Perl time value and then strftime or some such..... |
| 11:59 |
tsbere |
Dyrcona: [% USE date; date.format(due_date, 'strftime stuff') %] ? |
| 11:59 |
|
bmills joined #evergreen |
| 11:59 |
berick |
tsbere: the transaction is started one line above the output create call. |
| 11:59 |
tsbere |
berick: Ok, it has been a while since I needed to poke at that stuff |
| 12:00 |
berick |
starting to think this may just be an API call taking longer than the default recv timeout (60 seconds) |
| 12:00 |
Dyrcona |
tsbere: I was gonna look at that after lunch. I see a date.format there already, but couldn't remember if it took a date argument or not. |
| 12:00 |
tsbere |
Dyrcona: We have things like this in MVLC's templates: [% date.format(helpers.format_date(circ.due_date), '%Y-%m-%d') %] |
| 12:01 |
Dyrcona |
tsbere: Thanks. I thought something extra was needed. |
| 12:02 |
Dyrcona |
And, lunch... |
| 12:04 |
csharp |
berick: 12:01:39 start, 12:01:45 exit stateful session, 12:01:50 return with data to find no active transaction |
| 12:05 |
csharp |
so would upping the timeout to 12s or so be catastrophic? |
| 12:08 |
pinesol_green |
[evergreen|Dan Wells] Create/consolidate release notes for 2.11 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f7bf369> |
| 12:09 |
berick |
csharp: the thing is, you shouldn't have to. keepalive does not come into play while a drone is working on something. those times are coming from the cstore logs or the trigger logs? |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:13 |
berick |
IOW, need to confirm cstore is seeing the API call. If not, ejabberd is probably discarding the message because it's too big. |
| 12:14 |
berick |
which would explain why the drone times out waiting |
| 12:15 |
tsbere |
berick: Decided to take a look. xact_begin returns without doing anything if it believes there is already a transaction open. Perhaps something else isn't closing a transaction before then so a new one isn't opening? |
| 12:16 |
berick |
tsbere: could be. that would def. be bad. |
| 12:16 |
berick |
well, s/bad/explain the problem/ |
| 12:20 |
kmlussier |
dbwells++ #Was just going to ask about consolidating the release notes when I saw the commit come through. |
| 12:22 |
kmlussier |
dbwells: I noticed I got one of the header levels wrong when modifying the popularity badge/ranking note. When I merge the fix, will it be a problem to generate the release notes for the downloads page again? |
| 12:22 |
* kmlussier |
will also recheck the page one last time to make sure I didn't miss any other glaring errors. |
| 12:23 |
csharp |
berick: cstore does see the call |
| 12:23 |
csharp |
which is 405466 bytes |
| 12:23 |
berick |
csharp: ok.. so maybe tsbere is on to something. it's easy to test that one.. sec |
| 12:23 |
csharp |
ok |
| 12:25 |
berick |
csharp: mind seeing what happens if you add this line (and restart trigger) -- maybe on a dev server if possible |
| 12:25 |
berick |
https://gist.github.com/berick/f4e1ac051ac8860faaf72816d867b460 |
| 12:26 |
berick |
that's not necessarily the final form of a fix, just experimenting |
| 12:27 |
tsbere |
doesn't help that if that *does* do something then there are other possible problems, such as "who opened the transaction and did they try to write anything before it failed?", right? |
| 12:27 |
berick |
yeah, exactly |
| 12:29 |
|
mmorgan1 joined #evergreen |
| 12:36 |
* berick |
steps away for a bit |
| 13:02 |
csharp |
ugh - now I'm in a rabbit hole of trying to get logging working properly on my acq testing server :-/ |
| 13:11 |
|
sandbergja joined #evergreen |
| 13:17 |
* tsbere |
dislikes finding 42 bib records with a bad type character |
| 13:18 |
tsbere |
If anyone wants the query I used to *find* said bib records I am willing to share |
| 13:20 |
|
rlefaive joined #evergreen |
| 13:29 |
dbwells |
kmlussier: Took me a second, but I see the heading you are talking about now. Sure, I can regenerate/repost them when ready. |
| 13:31 |
kmlussier |
dbwells: Thanks! I've also caught a few typos that I missed on previous proofreading. Making the changes now. |
| 13:36 |
csharp |
berick: same behavior after that change |
| 13:38 |
csharp |
I was hopeful when a PO on our test server with 212 items printed, but the 313-long one that triggered the helpdesk ticket is still timing out |
| 13:39 |
berick |
csharp: ok, mind trying one more thing? |
| 13:39 |
csharp |
sure |
| 13:39 |
kmlussier |
Do we have a 2.11 release branch yet? |
| 13:40 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Minor fixes for 2.11 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c06d1b> |
| 13:40 |
berick |
csharp: one more additional line... https://gist.github.com/berick/94cbec013b8b5938f01f838a8070c641 |
| 13:41 |
csharp |
btw, in the DB logs, before the rollback, the template_output is inserted correctly |
| 13:41 |
berick |
k |
| 13:41 |
* kmlussier |
answers her own question with a 'no'. |
| 13:42 |
kmlussier |
dbwells: OK, I've merged the edits. Thanks! |
| 13:42 |
kmlussier |
dbwells++ |
| 13:42 |
* Dyrcona |
thought he saw it the other day, but musta been dreaming. |
| 13:43 |
kmlussier |
Dyrcona: Sounds like a fairly boring dream. |
| 13:43 |
Dyrcona |
:) |
| 13:45 |
kmlussier |
OK, then, a procedural question since I'm in the rare position of having a press release ready in time for the actual release instead of being weeks late. Is it okay to issue the press release now or should I wait until it is announced to the community? |
| 13:45 |
gmcharlt |
we serve current users first, no? |
| 13:46 |
gmcharlt |
I mean, not a big deal either way, but I think it is a courtesy to folks already using Evergreen to announce first, or at the same time as the PR |
| 13:48 |
kmlussier |
Sure, I can do it at the same time too. miker: do you have a sense yet on when you'll be posting announcements or are there still some things that need to be done with the release before that happens? |
| 13:50 |
csharp |
berick: same deal - No request was received in 6 seconds, exiting stateful session |
| 13:51 |
berick |
csharp: k, dang. oh well, enough throwing stuff at the wall. i'd have to see the logs to be of any more benefit. can revisit at the hackaway, unless you want to post logs |
| 13:53 |
csharp |
berick: I'll post logs after cleaning them up... do you want the logs with the changes you recommended, or should I revert those? |
| 13:53 |
berick |
w/ the changes is fine |
| 13:53 |
csharp |
k |
| 13:53 |
|
ssieb joined #evergreen |
| 13:59 |
berick |
can't remember if we're back-porting web staff fixes by default these days.. |
| 13:59 |
berick |
iow, if i should target 2.11 and 2.10 for bug fixes |
| 14:00 |
* berick |
also wonders if it's time for a new 2.11 target |
| 14:00 |
Dyrcona |
Yeah, just about time for a 2.11 target. I dunno if the branch should come first, though. |
| 14:01 |
csharp |
berick: http://evergreen-ils.org/~csharp/dead_at_po_process.log.gz |
| 14:01 |
csharp |
(too big for easily pastebin-ing |
| 14:01 |
csharp |
) |
| 14:02 |
berick |
csharp++ |
| 14:03 |
csharp |
berick++ # helpin' |
| 14:09 |
berick |
csharp: you said the output is successfully created in the DB before the transaction is rolled back? |
| 14:10 |
kmlussier |
berick: Yes, we've definitely been backporting web client circ fixes. I can't recall if we are for cataloging as well, but I would support cataloging backports. |
| 14:10 |
berick |
thanks kmlussier |
| 14:11 |
|
maryj joined #evergreen |
| 14:12 |
csharp |
berick: yes, I can see the complete HTML in the logs |
| 14:13 |
berick |
csharp: in what logs, though? PG logs? |
| 14:15 |
csharp |
berick: sorry, yeah |
| 14:16 |
* csharp |
verifies that for the run that matches those logs |
| 14:20 |
berick |
csharp: what's confusing is I see no indication in the logs that open-ils.cstore is seeing the output.create API call. |
| 14:20 |
csharp |
oh |
| 14:21 |
berick |
trigger sends the request, cstore's time out, trigger says "I got no response". |
| 14:21 |
berick |
it's acting very much like the message is not arriving at the cstore back-end |
| 14:21 |
csharp |
hmm - a previous run *did* show it |
| 14:22 |
berick |
csharp: maybe just check the ejabberd logs, see if there's a message-too-big error? |
| 14:26 |
csharp |
berick: not seeing anything unusual in the ejabberd log for that run :-/ |
| 14:26 |
* csharp |
sighs |
| 14:27 |
* tsbere |
is happy that the list of 42 bibs with bad item types he generated is already down to 28. Through fixing or deleting doesn't really matter (though fixing is more likely) :D |
| 14:28 |
berick |
csharp: i suppose another possibility is the ejabberd server is taking longer than 6 seconds to deliver the message, even if it's not too big (from a stanza size perspective). your ejabberd 'shaper' configs are match the docs? |
| 14:29 |
berick |
500000 |
| 14:29 |
csharp |
berick: here's the log from before your changes were applied: http://evergreen-ils.org/~csharp/dying_at_output.log.gz |
| 14:29 |
berick |
thanks |
| 14:30 |
csharp |
berick: yeah, ejabberd is configured to the docs' recommendations |
| 14:31 |
berick |
csharp: ah, ok, i see cstore getting the output call in these logs.. |
| 14:32 |
csharp |
right, that's what I saw before |
| 14:32 |
berick |
csharp: keepalive is 6 seconds? |
| 14:32 |
berick |
oh yeah |
| 14:32 |
berick |
duh |
| 14:32 |
berick |
i see that in the logs |
| 14:33 |
berick |
ok, dang, i see what's happening. the problem is the time it takes for the data to go back and forth between the drones. |
| 14:34 |
csharp |
aha |
| 14:34 |
csharp |
so trigger waits for cstore or something like that? |
| 14:34 |
berick |
cstore replies at 12:01:39, 12:01:50 trigger logs that it received the results |
| 14:35 |
berick |
that's when cstore times out |
| 14:35 |
csharp |
right |
| 14:44 |
berick |
csharp: in your copious free time, i'd be curious to know if changing the ejabberd shaper values has any effect on this. changing it from 500000 to 5000000 (adding a zero) for example |
| 14:46 |
csharp |
berick: I'll try that, sure |
| 14:53 |
berick |
funny, i've never seen this happen before, at least not in a way I knew it was happening. seems like it would have come up before. |
| 14:55 |
Dyrcona |
Well, it all seems eerily familiar to me, though I never got that far into looking into it. |
| 15:04 |
dbwells |
Heads up to all, I just pushed a rel_2_11 branch to split from master. |
| 15:05 |
Dyrcona |
dbwells++ |
| 15:05 |
csharp |
dbwells++ |
| 15:06 |
Bmagic |
I'm having an issue in the web based staff client for 2.11 where the patron search screen loads, then loads a second search section, then exposes the template for the menu with {{variable}} |
| 15:06 |
Bmagic |
dbwells++ |
| 15:08 |
kmlussier |
dbwells++ |
| 15:08 |
kmlussier |
Bmagic: That doesn't sound good. |
| 15:09 |
csharp |
berick: I see a new error that's concerning me: Event reacting failed with Can't call method "id" on an undefined value at /usr/local/share/perl/5.18.2/OpenILS/Application/Trigger/Reactor.pm line 460. |
| 15:09 |
csharp |
I'm assuming that's from the timeouts, but it wasn't in earlier logs |
| 15:09 |
Bmagic |
I probably have it mis configured somewhere - just wondering if that behavior meant anything |
| 15:09 |
csharp |
I replaced Reactor.pm with the stock 2.9 version, FYI |
| 15:15 |
Dyrcona |
csharp: That line number is from the stock 2.9 Reactor.pm or from you own? |
| 15:15 |
dbs |
csharp berick: thank you for doing this work, it seems very very similar to what we're seeing (albeit more with checkins than triggers) |
| 15:16 |
dbs |
because it seems superweird for a simple checkin to time out in the database |
| 15:17 |
* dbs |
was wondering if networking issues (like ipv6 routing madness from years past?) might also be playing a role |
| 15:17 |
kmlussier |
Bmagic: I'm unable to test the web client to see if I can replicate it, but there was a recent small fix to the patron search form that might be a starting point for your investigation. |
| 15:17 |
kmlussier |
ee711968 |
| 15:17 |
pinesol_green |
kmlussier: [evergreen|Galen Charlton] LP#1436987: webstaff - fix patron search form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ee71196> |
| 15:17 |
Bmagic |
thanks! |
| 15:21 |
Dyrcona |
csharp: That would indicate that the call to create the trigger in the database failed. |
| 15:21 |
Dyrcona |
Or timed out along the way, which you already know. :( |
| 15:22 |
Dyrcona |
Well, the event output, rather. |
| 15:22 |
berick |
dbs: well, this one is a problem with the size of the data, a blob of text way larger than any normal processing (unless you're bib records are .3 Megabytes in size) |
| 15:22 |
pinesol_green |
[evergreen|Dan Scott] Add a simple Item Information test for SIP server - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9dd9dca> |
| 15:29 |
csharp |
Dyrcona: stock as of 2.9.2 |
| 15:29 |
berick |
csharp: still on ubuntu 14.04? |
| 15:29 |
csharp |
berick: yep |
| 15:29 |
berick |
k |
| 15:29 |
Dyrcona |
csharp: Yeah, I figured it out. The line is offset by 2 from rel_2_9. :) |
| 15:30 |
csharp |
ah gotcha |
| 15:30 |
Dyrcona |
There was a small fix in April. |
| 15:30 |
Dyrcona |
Doesn't affect this, though. |
| 15:32 |
dbs |
with unapi and xml-in-json, I wouldn't be surprised to see us getting closer to .3 megabytes per bib! heh. |
| 15:32 |
berick |
yeah, xml-in-json-in-xml |
| 15:33 |
Dyrcona |
But MARC sets the limit at 99,999 bytes. :) |
| 15:34 |
dbs |
you made me consider xml-in-json-in-xml-in-marc you beast |
| 15:35 |
* Dyrcona |
hands out BLOBs. |
| 15:36 |
Bmagic |
kmlussier: phew - it turned out to be some sort of browser caching issue - opened incognito and violla |
| 15:36 |
kmlussier |
Bmagic: Glad to hear it! |
| 15:38 |
csharp |
I'm going to have to stop working on this until I get my test server updated - I'm monkeying around too much on the prod servers :-/ |
| 15:40 |
Dyrcona |
@bartender |
| 15:40 |
* pinesol_green |
fills a pint glass with Cantillon Saint Lamvinus, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/388/8954) |
| 15:43 |
|
maryj joined #evergreen |
| 16:01 |
dbs |
@blame add $who was monkeying around too much on the prod servers! |
| 16:01 |
pinesol_green |
dbs: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 16:02 |
|
dbs joined #evergreen |
| 16:02 |
dbs |
@blame add $who was monkeying around too much on the prod servers! |
| 16:02 |
pinesol_green |
dbs: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 16:02 |
dbs |
meh |
| 16:05 |
|
_adb joined #evergreen |
| 16:06 |
|
kmlussier joined #evergreen |
| 16:06 |
kmlussier |
OK, looks like I've gotten my daily Comcast outage out of the way for today. |
| 16:06 |
csharp |
@blame add $who was monkeying around too much on the prod servers! |
| 16:06 |
pinesol_green |
csharp: The operation succeeded. Blame #24 added. |
| 16:08 |
mmorgan |
kmlussier: The squirrels have called it a day early, apparently ;-) |
| 16:09 |
dbwells |
@blame 24 dbwells |
| 16:09 |
pinesol_green |
dbwells: dbwells was monkeying around too much on the prod servers! |
| 16:09 |
dbwells |
^^ truth ^^ |
| 16:10 |
dbwells |
need the @confess command |
| 16:17 |
kmlussier |
Ha ha. I'm not sure we want to be encouraging folks to share confessions in here. :) |
| 16:18 |
csharp |
@confess |
| 16:18 |
pinesol_green |
csharp: Must be because I had the flu for Christmas. |
| 16:26 |
|
bmills joined #evergreen |
| 16:29 |
Dyrcona |
@confess |
| 16:29 |
pinesol_green |
Dyrcona: I'm sorry, Dave. I'm afraid I can't do that. |
| 16:55 |
dbs |
oh SIP, oh Unicode. placeholder commit for our instance: http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=commit;h=6f9d44677c53cf3f4ae2aa1ada0ca313eb929a1b |
| 17:11 |
|
mmorgan left #evergreen |
| 17:13 |
|
bmills1 joined #evergreen |
| 17:16 |
|
bmills joined #evergreen |
| 17:55 |
|
bmills joined #evergreen |
| 23:37 |
|
Ilie` joined #evergreen |
| 23:55 |
|
serflog joined #evergreen |
| 23:55 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 23:59 |
|
berick joined #evergreen |
