| Time |
Nick |
Message |
| 02:05 |
|
yar_ joined #evergreen |
| 03:57 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-12T04:58:59,712036408-0400 -0> |
| 05:07 |
|
jamesrf joined #evergreen |
| 05:13 |
|
yar joined #evergreen |
| 07:00 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:56 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:46 |
|
bos20k joined #evergreen |
| 09:13 |
|
tlittle joined #evergreen |
| 09:23 |
|
yboston joined #evergreen |
| 09:34 |
|
bdljohn joined #evergreen |
| 09:43 |
|
sandbergja joined #evergreen |
| 09:59 |
|
dbwells_ joined #evergreen |
| 10:00 |
|
remingtron_ joined #evergreen |
| 10:01 |
|
pinesol` joined #evergreen |
| 10:07 |
|
dickreckard_ joined #evergreen |
| 10:11 |
|
berick joined #evergreen |
| 10:12 |
|
Dyrcona joined #evergreen |
| 10:12 |
|
berick joined #evergreen |
| 10:18 |
|
beanjammin joined #evergreen |
| 10:23 |
|
Christineb joined #evergreen |
| 10:33 |
|
aabbee joined #evergreen |
| 10:54 |
|
bdljohn1 joined #evergreen |
| 11:27 |
|
jihpringle joined #evergreen |
| 11:29 |
|
Stompro joined #evergreen |
| 11:37 |
|
mcgriff joined #evergreen |
| 11:37 |
|
sandbergja joined #evergreen |
| 11:51 |
csharp |
since moving to websocketd, we're seeing higher and more frequent single-brick load spikes than we saw under apache2-websockets |
| 11:51 |
csharp |
load average shoots up and drones for certain services (actor, settings, trigger) are exhausted |
| 11:52 |
csharp |
but a look across bricks shows that it's hammering one brick but the others are under-utilized |
| 11:53 |
* csharp |
has a dim memory of a conversation with miker about a similar observation last year when we first moved to the browser client |
| 11:53 |
berick |
csharp: websocketd can require more settings drones, which if they are exhausted, could impact other services. |
| 11:53 |
berick |
why it's on just 1 brick I can't say |
| 11:54 |
jeff |
berick: why does websocketd require more settings drones? |
| 11:55 |
berick |
jeff: each browser websocket connections sets up a new opensrf connection, so it has to load settings. apache2-websocket connected per apache child instance, which could server multiple websocket connections in its life. |
| 11:56 |
|
khuckins joined #evergreen |
| 11:56 |
berick |
websocketd has no concept of re-using forked processes |
| 11:57 |
berick |
csharp: curious what your proxy_send_timeout and proxy_read_timeout values are. |
| 11:58 |
csharp |
proxy_connect_timeout 5m; |
| 11:58 |
csharp |
proxy_send_timeout 1h; |
| 11:58 |
csharp |
proxy_read_timeout 1h; |
| 11:58 |
berick |
you'll want to lower those for websocketd |
| 11:58 |
csharp |
thats under the websocket gateway |
| 11:58 |
csharp |
oh ok |
| 11:58 |
csharp |
do you have a recommendation? |
| 11:58 |
berick |
proxy_send_timeout and proxy_read_timeout act as your inactivity timeouts for webosckets |
| 11:59 |
jeff |
berick: ah, got it. thanks! |
| 11:59 |
berick |
csharp: more like 3m |
| 11:59 |
csharp |
ah - that makes sense |
| 11:59 |
berick |
or 5m |
| 11:59 |
csharp |
I think I'll go for 5 mins and see where that gets us |
| 11:59 |
berick |
depends on how many websocketd processes you have sitting idle |
| 11:59 |
berick |
it's not a problem to have idle connections, unless it's eating resources |
| 12:00 |
berick |
to be clear, it only talks to opensrf-settings once, right when the process starts |
| 12:00 |
berick |
so idle connections won't impact opensrf.settings |
| 12:00 |
|
beanjammin joined #evergreen |
| 12:01 |
berick |
and a higher idle timeout can result in fewer calls to opensrf.settings since you have fewer idle clients getting kicked off. but certainly 1 hour is too high |
| 12:02 |
csharp |
berick++ # thanks for the suggestions |
| 12:09 |
Stompro |
Does anyone know if it is possible to add text formatting to egAlertDialog.open? I just want to add some extra line breaks to make it easier to read. But it looks like all HTML is escaped. |
| 12:10 |
berick |
Stompro: to all instances of the dialog? or just a specific case? |
| 12:11 |
berick |
Stompro: you can edit Open-ILS/src/templates/staff/share/t_alert_dialog.tt2 to add formatting globally. |
| 12:12 |
|
beanjammin joined #evergreen |
| 12:12 |
Stompro |
berick, just for a specific instance. |
| 12:13 |
berick |
Stompro: don't believe that would be possible w/o code changes |
| 12:15 |
berick |
Stompro: i suppose you could try some unicode tricks and see if the browser gobbles them up, like Vertical Tab, Next Line, etc. |
| 12:16 |
berick |
in the alert message |
| 12:16 |
berick |
i know the browser won't collapse U+2007 (space) |
| 12:18 |
Stompro |
\u000d seems to get ignored in the output. |
| 12:19 |
Stompro |
berick, unless that isn't the correct code.. but when I look at the source the newline does show. |
| 12:20 |
Stompro |
berick++ thanks for the pointers |
| 12:21 |
berick |
Stompro: i think for that to work, it has to be smoething besides a standard space / newline character |
| 12:22 |
berick |
something outside of the ascii range |
| 12:31 |
JBoyer |
The thing most likely to work (and safest/easiest to implemtent) would be to just transform \n to </br> after any HTML stripping. That way you get a minimum of formatting for readability without any real possibility of allowing security issues in. |
| 12:32 |
|
aabbee left #evergreen |
| 12:32 |
JBoyer |
Anything that relies on getting fancy with dark-alley unicode codepoints isn't likely to work consistently if at all. |
| 12:32 |
JBoyer |
(though they can be fun to play with) |
| 12:33 |
csharp |
@band add Dark-Alley Unicode Codepoints |
| 12:33 |
pinesol |
csharp: Band 'Dark-Alley Unicode Codepoints' added to list |
| 12:33 |
JBoyer |
@zalgo the center will not hold! |
| 12:33 |
pinesol |
JBoyer: uh huh.. please tell me more about that |
| 12:33 |
JBoyer |
And, no. |
| 12:33 |
berick |
JBoyer: that assumes we're editing the alert dialog code, which we're not doing (in this mental exercise anyway) |
| 12:34 |
JBoyer |
I know, that was just my roundabout way of saying "you should really edit the dialog box code" :) |
| 12:35 |
JBoyer |
But that's a really simple, safe edit vs a tag whitelist or trying to wedge a markdown interpreter somewhere into the tree. |
| 12:50 |
|
idjit joined #evergreen |
| 12:53 |
|
abowling joined #evergreen |
| 12:58 |
abowling |
in my first attempt at installing 3.1.x, i've found an error with "npm run build-prod". i also found the workaround is running the makefile install for [os]-[release]-developer, but curious if anyone else has run into this and has some light to shed |
| 12:59 |
berick |
abowling: you don't have to run any npm commands if you install from a tarball. |
| 12:59 |
berick |
if you install from source, you'll need the *-developer prereqs. |
| 13:01 |
abowling |
berick: thanks. i've previously operated from the install base non-developer tarball/install nodejs and npm separately. i infer from your message that maybe that's not an (ideal|worakable) workflow now? |
| 13:02 |
abowling |
*workable |
| 13:03 |
abowling |
it's also possible that i had a bad install with the non-developer tarball. i ran into other such wackiness. i'm really just at the point of intellectual curiosity of "did i do something wrong?" or "did something foul up?" |
| 13:04 |
|
yboston joined #evergreen |
| 13:07 |
berick |
abowling: well, the npm steps are done for you when you install from a release tarball |
| 13:07 |
berick |
all you need is the usual configure, make, make install |
| 13:07 |
abowling |
berick++ |
| 13:07 |
berick |
and that will copy the pre-compiled web files into place |
| 13:07 |
abowling |
berick: thanks. i think what you've confirmed is "something went wrong" |
| 13:08 |
abowling |
because i did it the same as ever. :) |
| 13:08 |
abowling |
i just found through google that miker had the exact same error, so wanted to make sure there wasn't something i missed |
| 13:38 |
|
jamesrf joined #evergreen |
| 14:28 |
sandbergja |
A patron was just able to renew their hold, even though "Block Renewal of Items Needed for Holds" is set to True, and that was the only copy that could have filled the hold (that bib also has an on-order copy record) |
| 14:29 |
sandbergja |
What are my next steps in troubleshooting? |
| 14:32 |
sandbergja |
FWIW, the hold was placed one day before the renewal took place |
| 14:35 |
jeff |
Do you know the circumstances of the renewal? Was it done by staff, who could have overridden the event? |
| 14:35 |
sandbergja |
jeff: it was an OPAC renewal |
| 14:35 |
sandbergja |
thanks for asking! I should have said |
| 14:35 |
jeff |
Is that org unit setting set at a high enough level to take effect? Top of tree, for example? |
| 14:36 |
sandbergja |
Yes, it's at the CONS level |
| 14:36 |
jeff |
Are you able to review logs? An INFO-level log message looking like circulator: searching for best hold at org ORGID and copy BARCODE |
| 14:37 |
sandbergja |
I'm not, but I can ask somebody who can -- thanks for the tip |
| 14:38 |
jeff |
Once you find that you can use the thread trace value for that message to see the other likely relevant log messages... |
| 14:38 |
jeff |
Is the hold in question suspended/frozen, or could it have been at the time of the renewal? |
| 14:40 |
csharp |
I have a not-so-clear memory of us having an issue with that feature in PINES - it was either too loose or too strict, I think |
| 14:41 |
jeff |
Well, it tends to err on the side of blocking renewal if the copy COULD fill a hold. |
| 14:42 |
sandbergja |
jeff: It is not currently frozen. Is there a way I can check its history (I didn't notice an auditor table for holds) |
| 14:42 |
jeff |
Which is why some organizations use circ/hold policy of "copy/hold ratio" in place of that org unit setting. |
| 14:43 |
jeff |
sandbergja: action.hold_request isn't audited by default, no. Log entries related to the hold are about the only way to detect a change in that case. |
| 14:43 |
rjackson_isl |
patron account in good standing and correct profile (that hold is for)? |
| 14:43 |
jeff |
once you hear back from the logs search, it would be interesting to know if you have a line "circulator: no suitable holds found for copy BARCODE_HERE" |
| 14:44 |
jeff |
sandbergja: do you use hold stalling at all? |
| 14:44 |
sandbergja |
rjackson_isl: oh, I hadn't thought to check! But they are in good standing: no fines and not expired. |
| 14:44 |
sandbergja |
jeff: I don't know -- how would I check? |
| 14:46 |
jeff |
sandbergja: what rjackson_isl said but also, no standing penalties that block CAPTURE? |
| 14:46 |
rjackson_isl |
newer item and age protection in play? |
| 14:46 |
sandbergja |
Oh, I found a soft stalling interval of 1 day |
| 14:47 |
jeff |
org unit setting circ.hold_stalling.soft -- "Holds: Soft stalling interval" |
| 14:47 |
jeff |
yeah, that's probably the issue, since you said that the hold was placed "one day before" the renewal. |
| 14:48 |
jeff |
can you see if the hold request time was less than 24 hours before the renewal time? |
| 14:48 |
rjackson_isl |
jeff++ less that 24 hours since last time hold was checked |
| 14:49 |
sandbergja |
hmmmmm... obnoxiously, it's almost exactly 25 hours |
| 14:50 |
sandbergja |
the hold was placed at 1:23pm on 8 March, the renewal happened at 2:58pm on 9 March |
| 14:50 |
jeff |
okay, and that's before the DST change, so... |
| 14:51 |
mmorgan |
sandbergja: How often does your hold targeter run? |
| 14:52 |
sandbergja |
mmorgan: good question! I can check |
| 14:52 |
rjackson_isl |
type of hold (part, copy or title) and target (do targets match with renewed item) |
| 14:53 |
sandbergja |
rjackson_isl: it's a title hold, and the target matches |
| 14:54 |
jeff |
do copy circ_lib, hold pickup_lib, and renewing patron home_ou all match, or are we dealing with multiple locations? |
| 14:58 |
sandbergja |
jeff: yes, they are all the same |
| 14:58 |
sandbergja |
Thanks for all the troubleshooting tips, all! |
| 15:06 |
rjackson_isl |
holdable flags on asset.copy and asset.copy_location might be off |
| 15:08 |
jeff |
you might also look at what users/groups have the COPY_NEEDED_FOR_HOLD.override permission. |
| 15:11 |
jeff |
potentially useful query for that, replace BARCODE_HERE with patron card barcode: select * from permission.usr_has_perm_at((select usr from actor.card where barcode = 'BARCODE_HERE'), 'COPY_NEEDED_FOR_HOLD.override'); |
| 15:13 |
jeff |
given a user without that permission, you'll get zero rows. if the user has that permission, you'll get one or more org unit ids. |
| 15:14 |
sandbergja |
Cool! |
| 15:14 |
sandbergja |
jeff++ |
| 15:14 |
sandbergja |
rjackson_isl++ |
| 15:14 |
sandbergja |
mmorgan++ |
| 15:14 |
sandbergja |
csharp++ |
| 15:46 |
jeff |
sandbergja: you realize you have to follow up and tell us what you find, right? :-) |
| 15:46 |
sandbergja |
jeff: I sure will! |
| 15:46 |
sandbergja |
:-) |
| 16:07 |
|
mmorgan left #evergreen |
| 16:18 |
Stompro |
I was just testing out an add on to item status that would allow pasting in a string of barcodes in CSV format... and I accidentally tried pasting in a string with 400K barcodes in CSV format. "This seems to be taking a while. hmm". |
| 16:20 |
Stompro |
Trying it out with 200 barcodes worked much better. |
| 16:38 |
|
beanjammin joined #evergreen |
| 17:00 |
|
sandbergja joined #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:12 |
|
sandbergja joined #evergreen |
| 18:22 |
Dyrcona |
So, I'm pretty sure that no one is around, but I just had an issue with the fine generator again, this time on a new VM setup just to run it and some other jobs that use storage. |
| 18:23 |
Dyrcona |
It is scheduled to run every hour on the hour. |
| 18:23 |
Dyrcona |
The one that starts at 6:00 pm reported that it was still running. |
| 18:23 |
Dyrcona |
The lock file is there, and so is the process. |
| 18:24 |
Dyrcona |
osrf_control --diagnostic says that there's no process with the storage listener's PID running. |
| 18:24 |
Dyrcona |
pgrep -af storage shows 7 drones, and no listener. |
| 18:28 |
* Dyrcona |
decides to open a Lp bug, but will write up in a text file, first. |
| 18:38 |
Dyrcona |
I wonder if this is bug 1206629? |
| 18:38 |
pinesol |
Launchpad bug 1206629 in Evergreen "Fine Generator timeout is different in single/parallel modes" [Medium,Triaged] https://launchpad.net/bugs/1206629 |
| 18:39 |
Dyrcona |
Could it just be timing out? |
| 18:50 |
Dyrcona |
Guess it takes a while to grep through a 1.2GB log file. |
| 18:53 |
|
jamesrf joined #evergreen |
| 19:06 |
|
HomerPublic joined #evergreen |
| 19:28 |
|
Dyrcona joined #evergreen |
| 20:57 |
|
sandbergja joined #evergreen |
