| Time |
Nick |
Message |
| 00:19 |
|
jonadab joined #evergreen |
| 07:07 |
|
rjackson_isl_hom joined #evergreen |
| 07:36 |
|
Dyrcona joined #evergreen |
| 08:11 |
|
mantis1 joined #evergreen |
| 08:11 |
|
rfrasur joined #evergreen |
| 08:16 |
|
mmorgan joined #evergreen |
| 08:19 |
|
collum joined #evergreen |
| 09:08 |
csharp |
berick: daily throttle fix report: looks like it's negatively impacting acq dojo UIs |
| 09:09 |
csharp |
gonna have to roll it back again :-( |
| 09:09 |
csharp |
I've got console errors to share though, give me a few |
| 09:10 |
csharp |
https://pastebin.com/qZ0rWidk |
| 09:15 |
csharp |
dojo-- |
| 09:27 |
csharp |
updated bug 1912834 |
| 09:27 |
pinesol |
Launchpad bug 1912834 in OpenSRF "Browser client should limit the number of parallel requests" [High,New] https://launchpad.net/bugs/1912834 |
| 09:36 |
|
Cocopuff2018 joined #evergreen |
| 09:37 |
|
jvwoolf joined #evergreen |
| 09:38 |
|
jvwoolf1 joined #evergreen |
| 09:54 |
berick |
csharp: many thanks for your testing. |
| 09:55 |
berick |
one thing we could do is optinally turn throttling on/off, only turn it on for testing/development, and when it hits the max it just stops and logs a bunch of info. |
| 09:55 |
berick |
forcing the dev to refactor |
| 09:57 |
berick |
or even a debug thottle mode (log only) and strict throttle mode (stop everything) |
| 10:04 |
Dyrcona |
Maybe we should just refactor? |
| 10:05 |
Dyrcona |
I was thinking about that a bit this morning before clocking in. I considered raising a related topic for the next developers' meeting, but decided not to do so at this time. |
| 10:06 |
berick |
Dyrcona: that's kind of my goal, is to isolate the trouble areas |
| 10:06 |
berick |
so they can be fixed |
| 10:08 |
Dyrcona |
Well, I was thinking something more ambitious, like refactoring OpenSRF and Evergreen almost completely to get more efficient and more easily maintained code. I thought we could aim for a 4.0 or 5.0 release and break backward compatibility. |
| 10:08 |
Dyrcona |
Then, I remembered how small our community is.... |
| 10:08 |
berick |
Dyrcona: got anything more specific? |
| 10:10 |
Dyrcona |
I've not actually made a list, but circulation could use some reorganization to remove redundancy and make it easier to work with the code as an example. We mentioned that earlier this week. |
| 10:10 |
Dyrcona |
We could look for alternatives to ejabberd on the back end. |
| 10:12 |
Dyrcona |
More consistent payloads from Open-ILS requests and real batch operations for more backend calls. |
| 10:14 |
Dyrcona |
I think the browser client does too much in some cases. I don't have specific examples, but I think there are places where the XUL client used backend calls that did more where the web staff client does all those steps via pcrud. |
| 10:17 |
Dyrcona |
It's easy to say all this. One of the reasons I don't bring it up in a serious venue is that I know we don't really have the time for something that ambitious, though I suppose it could be done piece by piece. |
| 10:21 |
Dyrcona |
Anyway, looks like I have local problems to fix. |
| 10:24 |
berick |
Dyrcona: well, more batch APIs and less client-side pcrud (when used just for ease) I think is generally agreed upon and is how we got in this DOS mess. |
| 10:24 |
berick |
most of the UI's I write now have perl API's dedicated specifically to the UI, so we're moving in the right direction |
| 10:31 |
berick |
csharp: fyi https://bugs.launchpad.net/opensrf/+bug/1912834/comments/6 |
| 10:31 |
pinesol |
Launchpad bug 1912834 in OpenSRF "Browser client should limit the number of parallel requests" [High,New] |
| 10:36 |
csharp |
berick++ # thanks! will apply and report back |
| 10:38 |
berick |
also bug 1913458 |
| 10:38 |
pinesol |
Launchpad bug 1913458 in Evergreen "Record bucket 'Add To Bucket' actions should be batched or serialized." [Undecided,New] https://launchpad.net/bugs/1913458 - Assigned to Bill Erickson (berick) |
| 10:39 |
berick |
wherein I say, "suggestions for a new LP tag to group these?" |
| 10:41 |
berick |
csharp: not sure if the logging patch would be helpful in your situation, since it requries viewing the browser console (at the right time) |
| 10:41 |
berick |
it's more for diagnosing specific cases where you have a starting point |
| 10:42 |
Dyrcona |
I don't want to be misconstrued. I'm not disparaging any of the efforts we've made so far. I think we could benefit greatly in the long run with some clean up and reoganization. |
| 10:42 |
csharp |
whoa Too many [760] active network requests in progress! Code requires refactoring to avoid so many active requests |
| 10:42 |
csharp |
that's loading a PO with 35 items |
| 10:43 |
csharp |
berick: it is very helpful, yes |
| 10:43 |
berick |
Dyrcona: i didn't take it as disparaging, i generally agree with you. i'm just trying to figure out what I can do right now. |
| 10:44 |
berick |
csharp: what API's precede the warning in the logs? |
| 10:44 |
Dyrcona |
Right. |
| 10:45 |
berick |
csharp: and you know what, it doesn't actually matter in the Dojo UI's because they use XHR instead of WebSockets. The browser limits XHR |
| 10:45 |
berick |
similar to how XUL did |
| 10:45 |
berick |
so, it's not actually running that many parallel against the server in the Dojo UI's |
| 10:45 |
csharp |
ok |
| 10:48 |
csharp |
looks like this.testOrderIdentPerms = function(org, callback) { |
| 10:49 |
csharp |
is what is running just before the increase in procs |
| 10:49 |
berick |
csharp: so, it should log the API names in the console. that's what I was curious about. |
| 10:49 |
berick |
but again, not too concerned about the Dojo UI's |
| 10:50 |
csharp |
gotcha |
| 10:56 |
|
jihpringle joined #evergreen |
| 11:21 |
|
sandbergja joined #evergreen |
| 11:36 |
|
sandbergja joined #evergreen |
| 11:39 |
|
troy__ joined #evergreen |
| 11:39 |
|
jamesrf_ joined #evergreen |
| 11:39 |
|
kip joined #evergreen |
| 11:40 |
|
laurie joined #evergreen |
| 11:40 |
|
eby joined #evergreen |
| 11:42 |
|
Christineb joined #evergreen |
| 11:43 |
|
jeffdavis joined #evergreen |
| 11:50 |
|
ejk_ joined #evergreen |
| 11:56 |
|
Cocopuff2018 joined #evergreen |
| 11:56 |
|
ejk_ joined #evergreen |
| 12:02 |
|
collum_ joined #evergreen |
| 12:09 |
|
alynn26 joined #evergreen |
| 12:18 |
Dyrcona |
berick++ |
| 12:18 |
|
ejk joined #evergreen |
| 12:36 |
|
laurie joined #evergreen |
| 12:36 |
|
Christineb joined #evergreen |
| 12:43 |
|
laurie joined #evergreen |
| 12:55 |
|
Christineb joined #evergreen |
| 13:00 |
|
jamesrf joined #evergreen |
| 13:00 |
|
eby joined #evergreen |
| 13:15 |
|
jamesrf joined #evergreen |
| 13:18 |
|
kip joined #evergreen |
| 13:19 |
|
eby joined #evergreen |
| 13:31 |
|
kip joined #evergreen |
| 13:32 |
|
eby joined #evergreen |
| 13:39 |
mantis1 |
I had a couple of printing questions. We have one library who is using a barcode font for pick up receipts (curbside services), but the staff wasn't able to get it to print in Hatch properly. So they use Chrome's printer dialog, but since a recent update to the browser, it no longer allows them to set a default paper roll size of 80x257mm so they need to manually select/manage it every time for printing. |
| 13:39 |
mantis1 |
I'm curious to know if anyone else had a similar issue. |
| 13:48 |
|
jvwoolf joined #evergreen |
| 13:52 |
mantis1 |
Also if anyone was able to make barcode font work with Hatch, I'd love to hear from you |
| 13:56 |
|
eby joined #evergreen |
| 14:15 |
|
jihpringle joined #evergreen |
| 14:18 |
|
collum joined #evergreen |
| 14:21 |
|
kip joined #evergreen |
| 14:26 |
|
nfBurton joined #evergreen |
| 14:45 |
|
kip joined #evergreen |
| 14:59 |
csharp |
mantis1: we haven't heard that here, as far as I know - we don't administer that level of things from our office (handled by on-site local system admins) |
| 15:00 |
csharp |
mantis1: am I to understand that it's two problems? 1) Hatch not working 2) Chrome not working? |
| 15:03 |
Bmagic |
mantis1: I've had pretty good luck embedding the fonts into the page. I can't say I've done that with any Evergreen print template, but just generally, I've printed barcode fonts in HTML with a little elbow grease |
| 15:16 |
mantis1 |
csharp: Right Hatch for some reason has an issue printing the barcode out |
| 15:16 |
mantis1 |
And Chrome is just being difficult to put it lightly |
| 15:30 |
|
mantis1 left #evergreen |
| 15:33 |
csharp |
@who broke PINES reports? |
| 15:33 |
pinesol |
Christineb broke PINES reports. |
| 15:34 |
Christineb |
hahahaha |
| 15:34 |
csharp |
@blame [someone] for breaking PINES |
| 15:34 |
pinesol |
Your failure is now complete, yeats. for breaking PINES |
| 15:34 |
csharp |
yeats: I knew it would be you |
| 15:34 |
Christineb |
it wasn't me |
| 15:34 |
Christineb |
:D |
| 15:34 |
csharp |
Christineb: :-) |
| 15:35 |
csharp |
(yeats is my alternate non-work nick) |
| 15:35 |
berick |
well you just blew your cover |
| 15:35 |
yeats |
csharp: how could you? |
| 15:38 |
Dyrcona |
I'm getting this in opac/deps when running npm install: npm WARN bootstrap 4.3.1 requires a peer of popper.js@^1.14.7 but none is installed. You must install peer dependencies yourself. |
| 15:38 |
Dyrcona |
This is with a working branch based on master. |
| 15:47 |
|
dbwells joined #evergreen |
| 15:55 |
csharp |
I've seen that before |
| 16:00 |
|
sandbergja joined #evergreen |
| 16:20 |
jeff |
mantis1 left, but we're printing barcodes in receipts using Hatch without issue, but we're printing those to a laser printer, not thermal receipt printer. I'm not sure I've tested printing to a receipt printer, but could. |
| 16:22 |
jeff |
we're using the "holds for patron" template to print available on-shelf at-this-library holds and a scannable barcode. pullers grab them off the hold shelf and check the items out on our selfchecks after scanning the barcode on the slip. |
| 16:22 |
jeff |
(the slips are then shredded) |
| 16:25 |
|
Cocopuff2018 joined #evergreen |
| 16:26 |
jvwoolf |
jeff: We are trying to get them to print to a thermal receipt printer. Trying to get it to print the patron barcode on the hold slip. Works without Hatch, but not with. |
| 16:27 |
jvwoolf |
We're also on a pretty old version of EG at this point |
| 16:36 |
jeff |
what happens when you try? |
| 16:37 |
JBoyer |
And how are you specifying the font to use in the template? |
| 16:43 |
jeff |
and do your results vary if you print through Hatch but to another printer, such as a laser printer on letter size paper? |
| 16:44 |
jeff |
(not that that's helpful, just potentially diagnostic) |
| 16:44 |
jeff |
we're using something like this: |
| 16:44 |
jeff |
<div style="font-family: 'Libre Barcode 39 Text'; font-size: 3rem">*{{ holds[0].patron_barcode }}*</div> |
| 16:44 |
jeff |
(and I don't remember offhand if patron_barcode was something we injected or if it was present in stock) |
| 16:45 |
jeff |
I think I injected a few things for convenience and/or out of necessity. |
| 16:46 |
jeff |
the asterisks are because we're using code39, and the code39 font was downloaded and installed from the github project: https://graphicore.github.io/librebarcode/documentation/code39 |
| 16:48 |
jeff |
Oh. That might be it there. If you're trying to use a locally-installed font it's likely going to work through Hatch, and if you're trying to use a dynamically loaded / "webfont" style font that might fail in Hatch. |
| 16:49 |
jeff |
(that's probably where JBoyer was going already) |
| 16:50 |
JBoyer |
Kind of! |
| 16:51 |
JBoyer |
I also wondered if all fonts installed locally are available to the javafx html engine, though I imagine so. |
| 16:52 |
|
mmorgan joined #evergreen |
| 16:54 |
|
troy__ joined #evergreen |
| 17:17 |
Bmagic |
what hits the unapi url? |
| 17:30 |
Bmagic |
just checking to see if Evergreen makes use of it or if it's for external vendors and whatnot? |
| 17:33 |
JBoyer |
I think it's used in the opac a bit. |
| 17:38 |
|
mmorgan left #evergreen |
| 18:01 |
Bmagic |
we see spikes of traffic on that URL, and I am considering a rate limit at the nginx layer |
| 18:02 |
berick |
Bmagic: that could be ebsco, the one that's been causing so many people issues |
| 18:02 |
Bmagic |
that's what I was thinking too :) |
| 18:02 |
Bmagic |
but we should* be able to handle it on our side rather than telling them to knock it off |
| 18:36 |
|
jihpringle joined #evergreen |
| 18:37 |
|
sandbergja joined #evergreen |
| 21:19 |
|
dbwells_ joined #evergreen |
| 21:22 |
|
kip joined #evergreen |
