Time |
Nick |
Message |
00:31 |
* dbs |
slow-claps for process 12313, which has served 718 requests and is over 360MB and growing |
01:03 |
pinesol_green |
[evergreen|Bill Erickson] LP#1526159 Webstaff Items Out includes overdue, etc. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fcd65eb> |
01:21 |
pinesol_green |
[evergreen|Josh Stompro] LP#1494750 - Extra closing curly bracket in style.css disables following css - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e1a163f> |
06:40 |
|
rlefaive joined #evergreen |
07:01 |
|
agoben joined #evergreen |
07:02 |
csharp |
kmlussier++ |
07:16 |
|
rjackson_isl joined #evergreen |
08:19 |
|
krvmga joined #evergreen |
08:23 |
jeff |
dbs: regarding your conversation with Apache this morning: is the server_status count showing requests and not connections, while MaxConnectionsPerChild is counting connections not requests? |
08:26 |
jeff |
(where one connection may serve up to MaxKeepAliveRequests requests) |
08:27 |
* jeff |
starts to wonder if he's running a config different from that which is on disk. short of hijacking a configured perl handler with code that would attempt to read config settings, i'm not sure if there's a way to check that. |
08:51 |
StomproJosh |
csharp, re bug 1616220 - There are a bunch of dojo related warnings that my fix doesn't touch. So it doesn't get rid of all the warnings, just reduces the number of them. I can provide some specific examples to make testing easier. |
08:51 |
pinesol_green |
Launchpad bug 1616220 in Evergreen "XUL Staff Client CSS Fixes" [Undecided,New] https://launchpad.net/bugs/1616220 |
09:02 |
|
bos20k joined #evergreen |
09:07 |
|
mmorgan joined #evergreen |
09:24 |
|
Dyrcona joined #evergreen |
09:26 |
dbs |
jeff: since restarting apache with the new lean-and-mean approach, none of the processes are living long (longest one is 5 minutes instead of 5 hours) |
09:26 |
|
yboston joined #evergreen |
09:27 |
Stompro |
JBoyer, One of our system directors was part of Evergreen Indiana a while back. She remembers there being a staff initials field, or something like that, in the patron registration form. Is that something you still do? |
09:27 |
dbs |
but the server_status display shows an "Acc" column of 0/85/1186 and I was interpreting the "85" as # requests (per the legend at the bottom "Acc: Number of accesses this connection / this child / this slot") |
09:28 |
dbs |
But yeah, maybe I was interpreting it wrong, and now that I'm dropped KeepAlive to 2 from 5 there are more connections turning over |
09:28 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1623955: Keep periods in subject links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4c7efc> |
09:32 |
csharp |
Stompro: thanks - I'll re-test with your new info when you post them :-) |
09:33 |
csharp |
Stompro: re: staff initials, at least one of our libraries uses patron stat cats for that |
09:36 |
Stompro |
csharp, thanks for the staff initials info. |
09:42 |
JBoyer |
Stompro, csharp, I was going to say, initials for patron reg wasn't ringing any bells for me, but csharp's stat cat idea is a good one. I'd poll your members and see if it's worth making a consortium wide stat cat rather than trying to talk a lot of libs through it through it. |
09:44 |
|
kmlussier joined #evergreen |
10:10 |
kmlussier |
@coffee [someone] |
10:10 |
* pinesol_green |
brews and pours a cup of El Salvador Pacamara Los Planes, and sends it sliding down the bar to artunit |
10:10 |
kmlussier |
@tea [someone] |
10:10 |
* pinesol_green |
brews and pours a pot of Huang Shan Mao Feng Green Tea, and sends it sliding down the bar to artunit (http://ratetea.com/tea/teavivre/huang-shan-mao-feng-green-tea/6041/) |
10:11 |
kmlussier |
pinesol_green is being very generous to artunit today. :) |
10:11 |
pinesol_green |
kmlussier: BIG LETTERS MEAN BIG IDEAS, AM I RIGHT THOUGHT LEADERS? |
10:11 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
10:12 |
Dyrcona |
@swill [someone] |
10:12 |
* pinesol_green |
grabs a can of Sparks Light and sends it sliding down the bar to Dyrcona |
10:12 |
Dyrcona |
lol |
10:12 |
artunit |
i appreciate it! |
10:12 |
Dyrcona |
I think its prng is broken. ;) |
10:12 |
berick |
@swill |
10:12 |
* pinesol_green |
grabs a bottle of Pink Champale and sends it sliding down the bar to berick |
10:12 |
berick |
well la dee da |
10:13 |
Dyrcona |
I don't think I've ever had it pick me when I did [someone] before. |
10:14 |
bshum |
Nothing to prevent it from doing so. |
10:17 |
Dyrcona |
True. |
10:18 |
kmlussier |
It's a little early in the morning to start drinking Pink Champale. |
10:23 |
* kmlussier |
wonders if there is ever a good time to drink sparkling pink malt liquor. |
10:24 |
berick |
sparkling pink alt Liquor |
10:24 |
berick |
heh |
10:25 |
Dyrcona |
kmlussier: The late '70s? :) |
10:25 |
berick |
enter-while-editing-- |
10:25 |
Dyrcona |
editing-while-drinking-pink-champale-- :) |
10:25 |
kmlussier |
:) |
10:26 |
berick |
*hiccup* |
10:26 |
csharp |
@blame pink alt liquor |
10:26 |
pinesol_green |
csharp: pink alt liquor stole bshum's tux doll! |
10:27 |
bshum |
Noooooo |
10:27 |
* bshum |
hugs his penguin close |
10:27 |
Dyrcona |
alt liquor... Is this Usenet? |
10:27 |
Dyrcona |
alt.liquor.malt.pink |
10:28 |
Dyrcona |
alt.binaries.liquor.malt.pink |
10:28 |
Dyrcona |
:) |
10:28 |
|
Christineb joined #evergreen |
11:13 |
|
brahmina joined #evergreen |
11:50 |
Stompro |
Hmmm, our production DB doesn't have the function permission.grp_descendants ? That should be there, shouldn't it? |
11:51 |
csharp |
Stompro: yes, it should |
11:52 |
Dyrcona |
Actually, no. |
11:52 |
Dyrcona |
permission.grp_descendants_distance is the official one. |
11:52 |
csharp |
it's in the seed data and in upgrade scripts, no? |
11:53 |
Dyrcona |
csharp: It's not present in a 2.9.5 production db. |
11:53 |
Dyrcona |
But, I guess it depends on release. |
11:53 |
Dyrcona |
I didn't check the files. |
11:53 |
csharp |
it is present on our 2.9.1-ish |
11:53 |
Stompro |
I'm confused also, I see it in the seed data. |
11:54 |
csharp |
I use it in a cron job I run to set patron accounts to inactive nightly |
11:54 |
|
jihpringle joined #evergreen |
11:54 |
berick |
it's in my master db |
11:54 |
Dyrcona |
A grep of the code from rel_2_10 only turns up premissiong.grp_descendants_distance. |
11:55 |
csharp |
same here |
11:55 |
csharp |
(in my master db, installed yesterday from source) |
11:55 |
csharp |
from git, that is |
11:56 |
Dyrcona |
It shows up in 006 in master, and is referenced in an upgrade script but not created in an upgrade script in master. |
11:56 |
Dyrcona |
I'd say there's a problem there. ;) |
11:56 |
csharp |
yeah - I can confirm it's not in rel_2_10 |
11:57 |
Dyrcona |
Oh, wait. It is created in 0979. |
11:57 |
Dyrcona |
So, it's new. |
11:57 |
Dyrcona |
I missed the create or replace function in my grep output. |
11:57 |
csharp |
right |
11:57 |
csharp |
I just saw the same thing |
11:57 |
Dyrcona |
So, unless you're on 2.11, I guess it shouldn't be there. |
11:58 |
* csharp |
wonders why it's in his db :-/ |
11:58 |
Dyrcona |
csharp: I almost created one for MVLC as a custom function, but rewrote my script to the *_distance function. |
11:58 |
Dyrcona |
to [use] the. |
11:58 |
Stompro |
Dyrcona++, csharp++ GrepDetectives - thanks for looking. |
11:59 |
csharp |
:-) |
11:59 |
* csharp |
wanders off |
12:00 |
Stompro |
I'll use grp_descendants_distance, thanks for that info. |
12:00 |
Dyrcona |
Stompro: You could backport it to your db from 0979. |
12:01 |
Dyrcona |
The create or replace function will make the upgrade harmless. |
12:03 |
Stompro |
Dyrcona, I think that is out of my comfort level right now. I'm fine creating functions in custom schemas, but a little nervous touching the official ones. I'll get there, but not on read only friday. :-) |
12:04 |
Dyrcona |
Sure. That's understandable. |
12:07 |
* Dyrcona |
spent most of the morning in git, anyway. |
12:07 |
mmorgan |
Stompro++ # read only friday :) |
12:08 |
Dyrcona |
heh |
12:14 |
|
rlefaive_ joined #evergreen |
12:24 |
|
gsams joined #evergreen |
12:37 |
berick |
pro tip: if you set age values for the history.hold.retention_age* global flags, but don't enable them, action.purge_holds() will purge/age every canceled and fulfilled hold in the DB. |
12:37 |
berick |
test_servers++ |
12:38 |
miker |
Use this one "weird" trick to get rid of all your old holds! |
12:38 |
berick |
haha miker++ |
12:57 |
|
rlefaive joined #evergreen |
13:04 |
|
rlefaive joined #evergreen |
13:05 |
dbs |
For those keeping score (and for my future self): staff reaction to MaxKeepAliveRequests 100 / KeepAliveTimeout 2 / StartServers 5 / MinSpareServers 5 / MaxSpareServers 10 / MaxRequestWorkers 75 / MaxConnectionsPerChild 250 has been "XUL staff client is slower, more network timeouts" |
13:05 |
kmlussier |
:( |
13:06 |
dbs |
On the bright side, 10GB of free memory (the apache children are getting killed frequently) |
13:06 |
Dyrcona |
I would think so. |
13:07 |
dbs |
Of course that's 10GB of wasted memory too. |
13:08 |
Dyrcona |
dbs: I think the recommendation is 1 second on the keepalivetimeout. Other than that, you're on your own to figure out what works for your site. :) |
13:08 |
dbs |
Dyrcona: I started with the recommendations. |
13:08 |
Dyrcona |
But, I'm almost 100% certain that MaxRequestWorkers 75 is too low. |
13:09 |
Dyrcona |
dbs: Recommendations or defaults? |
13:09 |
dbs |
It's been a month of figuring out "what works" for my site since upgrading from 2.7, where the recommendations worked. |
13:09 |
dbs |
No, we've never even come close to 75 apache workers |
13:09 |
Dyrcona |
Ok, then. |
13:10 |
Dyrcona |
MVLC used to get hundreds on the public side. |
13:10 |
Dyrcona |
I spent a great deal of time working things out for MVLC, and I doubt it was ever close to perfect before I left. |
13:11 |
dbs |
Dyrcona: yeah, your blog posts have been very useful |
13:11 |
dbs |
yours and tsbere's |
13:11 |
Dyrcona |
There's also stuff in the IRC logs over that past year or two. Mostly just me rambling and complaining. :) |
13:12 |
Dyrcona |
I'm inclined to blame some combination of what we're doing with mod_perl and Apache 2.4. |
13:12 |
Dyrcona |
It didn't seem to be so bad on Apache 2.2 |
13:12 |
dbs |
Dyrcona++ # rambling and complaining, that's my role! |
13:12 |
Dyrcona |
But, I'd need to take the time to learn how to debug that sort of thing. |
13:13 |
Dyrcona |
heh |
13:16 |
|
maryj joined #evergreen |
13:53 |
|
rlefaive joined #evergreen |
14:31 |
* kmlussier |
is starting a draft agenda for next week's dev meeting. |
14:32 |
kmlussier |
If you want me to add anything, let me know. Or you can add it later. |
14:40 |
dbs |
hmm, should I be concerned about "File does not exist: /openils/var/web/xul/blah/server/main/OpenILS/data.js"? |
14:41 |
dbs |
The file does exist at /openils/var/web/xul/blah/server/OpenILS/data.js |
14:43 |
dbs |
Weirdly, there are successful (HTTP 200) requests for /xul/2106_conifer/server/OpenILS/data.js, followed 20 seconds later by HTTP 404 fails for /xul/2106_conifer/server/main/OpenILS/data.js |
14:44 |
|
rlefaive joined #evergreen |
14:45 |
dbs |
grep suggests everything expects server/OpenILS/data.js so I guess it's something dynamic. Dynamically broken! weird. |
15:05 |
kmlussier |
Draft agenda is available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-09-07 . Feel free to add to it. |
15:07 |
berick |
kmlussier++ |
15:18 |
kmlussier |
gmcharlt++ #Volunteering to run the meeting |
15:19 |
kmlussier |
dbwells++ #Picking up on my date mistakes in the agenda. |
15:25 |
kmlussier |
New link to draft agenda: https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2016-10-05 |
15:28 |
|
_bott_ joined #evergreen |
15:47 |
|
yboston_ joined #evergreen |
15:54 |
kmlussier |
@weather |
15:54 |
pinesol_green |
kmlussier: Seekonk, MA :: Rain :: 58F/14C | Friday: Showers possible. Lows overnight in the mid 50s. Friday Night: Cloudy with showers. Low 54F. Winds NE at 10 to 20 mph. Chance of rain 90%. |
16:11 |
|
DPearl joined #evergreen |
16:14 |
|
jeff_ joined #evergreen |
16:24 |
mmorgan |
I know it's late on Friday afternoon, but here goes... |
16:24 |
mmorgan |
I changed a hold policy from not holdable to holdable |
16:25 |
mmorgan |
I expected to manually retarget an existing hold and have it target an available item. |
16:25 |
mmorgan |
It's not targeting the item, but when the hold targeter runs, I see a few items added to the pull list. |
16:26 |
mmorgan |
Is there something that needs to happen after changing a hold policy before I can manually retarget? |
16:28 |
csharp |
mmorgan: the targeter doesn't consult those, as far as I know - those are for when the hold is placed |
16:28 |
csharp |
basically they answer "are we going to allow this patron place a hold in this place on this item?" |
16:29 |
Dyrcona |
mmorgan: I would also check the item for holdability, plus its copy location, etc. |
16:29 |
csharp |
the targeter *does* know about item and shelving location attributes, though |
16:29 |
csharp |
right |
16:30 |
mmorgan |
Ok, item is holdable, copy location is holdable. I can place a hold from the catalog on a record with only one item (belonging to the library to which the policy applies). |
16:31 |
mmorgan |
The hold is successful, but the item isn't targeted. |
16:32 |
Dyrcona |
Have you tried manually retargeting the hold in the staff client? |
16:32 |
mmorgan |
Dyrcona: Yes, it's not working |
16:33 |
Dyrcona |
mmorgan: Is it finding a copy, just not this copy? |
16:33 |
* csharp |
would go log diving |
16:33 |
jeff |
quality mismatch on the hold / copy? |
16:34 |
jeff |
copy library closed? |
16:34 |
Dyrcona |
yeah. didn't think of those. |
16:34 |
jeff |
(and OU settings that would override that not set?) |
16:34 |
Dyrcona |
also the copy status, but I just assumed it was available. |
16:34 |
jeff |
if you scan the item to capture, does it capture for that hold? |
16:35 |
jeff |
and yes, copy status as Dyrcona suggested |
16:35 |
jeff |
those are some reasonably common things that could prevent a copy from being selected as current_copy (and showing on a pull list) |
16:35 |
Dyrcona |
so many moving parts in holds. |
16:36 |
jeff |
there's at least one other that i'm trying to think of, but it escapes me. next up might be examining logs, as csharp suggests. |
16:37 |
Dyrcona |
jeff: age hold protection? i kind of assumed that wouldn't apply, either. |
16:38 |
jeff |
if age hold protection were in effect (transit required, copy recently created/active), it would have in theory thrown an overridable warning when placing the hold. |
16:38 |
jeff |
though i think if the hold were staff-placed there might be a scenario where the warning isn't shown. i'd have to double check. |
16:41 |
mmorgan |
Oh, ok. The library is closed. But some things are targeting. Checking some other library settings... |
16:43 |
jeff |
for holds that were targeted while the library was open and had current_copy set to a copy at that library, i'd expect them to remain until the hold is targeted again (automatically or manually) |
16:44 |
mmorgan |
"Target copies for a hold even if copy's circ lib is closed IF the circ lib is the hold's pickup lib" was false. When I changed it to true, I was able to retarget manually. |
16:45 |
mmorgan |
jeff++ Dyrcona++ |
16:45 |
Dyrcona |
jeff++ |
16:46 |
jeff |
my work here is done! |
16:46 |
mmorgan |
and csharp++ |
16:46 |
jeff |
quite literally -- have a good weekend, all! :-) |
16:48 |
* mmorgan |
expects the library's pull list to fill up the next time the targeter runs |
17:06 |
|
mmorgan left #evergreen |