| Time |
Nick |
Message |
| 01:44 |
|
Mark__T joined #evergreen |
| 07:00 |
|
kmlussier joined #evergreen |
| 07:00 |
|
mceraso joined #evergreen |
| 07:00 |
|
bshum joined #evergreen |
| 07:00 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 07:44 |
|
rjackson_isl joined #evergreen |
| 07:59 |
|
remingtron joined #evergreen |
| 08:25 |
|
graced joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:40 |
|
Shae joined #evergreen |
| 08:48 |
|
RoganH joined #evergreen |
| 08:51 |
|
mrpeters joined #evergreen |
| 08:53 |
|
dbwells joined #evergreen |
| 08:54 |
|
akilsdonk joined #evergreen |
| 09:10 |
|
collum joined #evergreen |
| 10:10 |
|
berowskim joined #evergreen |
| 10:11 |
jeff |
well that's a little odd. i have 84 entries for this home_ou in staging.usr_stage, but unless i tell the staff client to retrieve a very large number of patrons, i don't see the latest. |
| 10:12 |
jeff |
then after a few attempts, i start seeing the latest even with the lower than large number. |
| 10:12 |
|
maryj joined #evergreen |
| 10:15 |
jeff |
i see no caching in the relevant methods on the server... |
| 10:21 |
jeff |
server logs show the cstore search always returning all 84 results. |
| 10:22 |
jeff |
closing the staff client pending patron window with the limit set to 100 and then re-opening that tab results in only loading 48 patrons in the list. |
| 10:23 |
jeff |
hit refresh (still with limit of 100), get 80 patrons. |
| 10:29 |
jeff |
change to 101, refresh, get all 84. change to 100, refresh, get 80. |
| 10:31 |
tsbere |
jeff: Perhaps your system is haunted and the spirit doing so is messing with you. |
| 10:31 |
tsbere |
Or, you know, things are just weird. Either way. :P |
| 10:54 |
|
jboyer-isl joined #evergreen |
| 10:56 |
jeff |
and sometimes i just can't get it to load more than 80. |
| 10:56 |
jeff |
other times, loads 'em all on the first try. |
| 10:56 |
jeff |
(but then refresh does not load them all) |
| 10:57 |
jeff |
(except when it does) |
| 10:57 |
tsbere |
I wonder if it is a client race condition type issue with some entries overwriting others as they are written into the list |
| 10:58 |
jeff |
it seems to always be the most recent that don't load, which makes me wonder (after checking a few other things first) if it's a chunking/streaming thing. |
| 10:58 |
tsbere |
That could be too. Hmmm. |
| 10:59 |
jeff |
i'm going to run a few requests via the gateway to see if i can narrow down "client issue or server issue?" |
| 11:06 |
|
Christineb joined #evergreen |
| 11:08 |
jeff |
yeah, seven server requests all return identical, complete data. |
| 11:11 |
jeff |
though, i suppose if my requests are via osrf-gateway-v1 and the dojosrf ones are via the translator... |
| 11:12 |
|
yboston joined #evergreen |
| 11:27 |
miker |
jeff: is the translator response streaming or atomic? if the former, I'd suspect multipart-replace "fun" in xulrunner |
| 11:28 |
miker |
it gets ... unreliable ... past a certain number of result chunks (unrelated to chunking/bundling on the pure-xmpp side) |
| 11:31 |
jeff |
miker: this suggests to me that the method itself supports streaming: $conn->respond(flesh_user_stage($e, $_)) for @$stage_ids; |
| 11:31 |
jeff |
miker: am i correct in my thinking there? |
| 11:31 |
jeff |
i'm fairly certain the client is not calling the atomic variant of the method. |
| 11:31 |
miker |
jeff: you're correct |
| 11:37 |
jeff |
87 entries, client frequently gets stuck at 48 or 80. of course, only in production, where it's harder to fiddle with it. :-) |
| 11:40 |
dbs |
Poor old XULRunner |
| 11:55 |
|
rlefaive joined #evergreen |
| 11:55 |
|
abowling left #evergreen |
| 11:57 |
jeff |
yeah. |
| 11:57 |
|
edoceo joined #evergreen |
| 12:01 |
jeff |
look at the flowers, xulrunner... |
| 12:01 |
yboston |
when creating DB upgrade scripts in Open-ILS/src/sql/Pg/upgrade, what is hte community term for the serial number file prefix? i.e. 0016.data.patron-claim-return-perm.sql |
| 12:05 |
bshum |
yboston: Generally |
| 12:05 |
bshum |
For a contributor, we recommend using no number |
| 12:05 |
bshum |
And marking it like XXXX.name.sql |
| 12:06 |
bshum |
When the core committer adds it to Evergreen, they will renumber the script |
| 12:06 |
yboston |
bshum: I should have mentioned that I exptec somebody else to pick the number |
| 12:06 |
bshum |
And use the next available number. |
| 12:06 |
yboston |
is there a name for that number? |
| 12:06 |
bshum |
It's the number for the upgrade script. |
| 12:06 |
* bshum |
shrugs |
| 12:07 |
bshum |
I don't know if there's any other formally adopted name for it... it's just a number to me. |
| 12:07 |
bshum |
:D |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:07 |
yboston |
bshum: good enough for me, I just wanted to make sure I used a term that was used by the community |
| 12:08 |
yboston |
who puts together the corrsponding file that goes into Open-ILS/src/sql/Pg/version-upgrade, is that the RM or should I make a draft one for the RM or someone else to use? |
| 12:15 |
bshum |
yboston: The RMs create version-upgrade scripts automatically as part of the make_release step of release work |
| 12:16 |
yboston |
bshum: thanks! This really helps to see what I need to include in the DB upgrade part of my bug fix |
| 12:16 |
bshum |
the make_release script goes out and grabs all the numbered scripts from the upgrades dir and compiles them. |
| 12:16 |
yboston |
cool |
| 12:16 |
bshum |
so contributors only need to add an upgrade script file. |
| 12:17 |
bshum |
After that, the rest is handled by core committers / RM |
| 12:17 |
bshum |
For the upgrade script file |
| 12:17 |
bshum |
Lately I've seen people leave the number check commented out |
| 12:17 |
bshum |
And that's actually helpful for testing purposes. |
| 12:17 |
bshum |
Or at least it is for people like me, who has potentially multiple branches loaded up at once with test scripts |
| 12:19 |
tsbere |
I believe the number in the upgrade SQL script filenames is the upgrade script version number. If only because it ends up in a column named "version". :P |
| 12:19 |
yboston |
tsbere: thanks |
| 12:22 |
yboston |
bshum: you are reffering to code like: SELECT evergreen.upgrade_deps_block_check('0887', :eg_version); |
| 12:22 |
yboston |
? |
| 12:26 |
bshum |
Yes, that check should be in the file at the beginning. Well after the BEGIN; anyways :) |
| 12:26 |
* bshum |
wanders |
| 12:30 |
Stompro |
yboston, "Insert into yboston.todo values ('stompro', Test Josh's pgtap test public.lowercase because he tested yours")" |
| 12:30 |
Stompro |
yboston, :-) |
| 12:33 |
|
dcmh joined #evergreen |
| 12:33 |
tsbere |
Stompro: I believe you have an unmatched quote error there. And depending on SQL language details, an incorrect quote type error. :P |
| 12:35 |
yboston |
Stompro: you also signed off my accesibility patch too, I am in your debt |
| 12:40 |
* jeff |
is tempted to change the pending patrons call to be atomic in the xulrunner client, or change the ordering of the underlying query to be most-recent-first |
| 12:42 |
tsbere |
jeff: I have been known to create an extra server-side client folder for testing that kind of tinkering when I couldn't make the changes 100% locally and was only seeing issues in production. |
| 12:42 |
tsbere |
jeff: At least in regards to changing to the atomic version |
| 12:42 |
* jeff |
nods |
| 12:43 |
jeff |
i found some immediate relief by deleting some staged users who were 12 or 13 days old (usually we delete at 14) |
| 13:30 |
|
jlitrell joined #evergreen |
| 13:31 |
berick |
RoganH: kmlussier: thinking about booking my hackaway flight soon. do we have a genearl idea of what ideal arrival and departure times are? |
| 13:31 |
berick |
i'm planning to come tuesday afternoon and leave friday afternoon |
| 13:36 |
|
buzzy joined #evergreen |
| 13:38 |
berick |
oh, right, i think kathy said something about being on vacation. |
| 13:38 |
RoganH |
berick: if folks come into Logan apparently it's close enough that finding a volunteer to drive folks shouldn't be a problem. |
| 13:39 |
berick |
RoganH: great, so basically, as long as I don't fly in at 2am |
| 13:39 |
RoganH |
berick: Kathy has already beat the drum for folks who work and live near Logan and she wasn't concerned about driving folks coming into Logan. |
| 13:39 |
RoganH |
berick: yep |
| 13:39 |
RoganH |
berick: the other airport was more of a problem because she only has one person (her) who lives near it. |
| 13:40 |
berick |
gotcha. thanks, RoganH |
| 13:40 |
RoganH |
I'll throw up a google doc though for folks to list when they're flying in to make it easier to coordinate picking up and dropping folks off. |
| 13:41 |
berick |
was going to suggest the same. sounds good |
| 13:42 |
RoganH |
I'll send it out by email too: https://goo.gl/bnbqta |
| 14:49 |
|
yboston joined #evergreen |
| 14:56 |
|
drigeny joined #evergreen |
| 14:56 |
|
BigRig_ joined #evergreen |
| 15:46 |
Stompro |
Is anyone familiar with the "circ.holds.max_org_unit_target_loops" "Maximum library target attempts" setting? Is that counting each time the hold targeter is run? |
| 15:49 |
Stompro |
So if our holds targeter runs every 15 minutes, 96 times a day, a setting of 192 would give a site 2 days to fill a hold before being skipped? |
| 15:49 |
tsbere |
I believe that works somewhat differently than that |
| 15:50 |
tsbere |
For starters, a hold won't run through the targeter every 15 minutes under normal circumstances (I believe defaults are "each hold is looked at once a day") |
| 15:51 |
Stompro |
tsbere, thanks, I'm trying to get up to speed on EG holds this week. |
| 15:51 |
mmorgan |
Stompro: We have not set the maximum target attempt setting, but my understanding was it looked at the number of times each library was targeted for the hold. |
| 15:52 |
tsbere |
Stompro: I will note we don't use that setting, so I am not an expert on it. |
| 15:52 |
tsbere |
On the other hand, I believe it is more of a "by the pickup library" thing than a targeted library thing |
| 15:52 |
mmorgan |
Stompro: You're only giving yourself a week? ;-) |
| 15:53 |
Stompro |
So the "circ.holds.max_org_unit_target_loops" is closer to a days count? |
| 15:53 |
* tsbere |
looks at the code |
| 15:54 |
|
drigeny joined #evergreen |
| 15:54 |
tsbere |
From a very basic examination.....each "loop" will exclude libraries from targeting the hold, one session at a time. When you run out of copies all exclusions are disregarded and the loop number is incremented. |
| 15:55 |
tsbere |
When you run out of loops the hold is canceled |
| 15:55 |
* tsbere |
isn't sure what this is supposed to accomplish |
| 15:57 |
tsbere |
Also looks like the entire dance is ignored if it can target a copy at the pickup library |
| 16:00 |
Stompro |
tsbere, thanks for taking a look... this doesn't sound very useful to us. I wonder if it is to limit holds sticking around forever, for large systems. Let the item try to be found once or twice at all possible locations, but if it doesn't work, give up? |
| 16:00 |
* tsbere |
shrugs |
| 16:01 |
mmorgan |
Stompro: I think that's exactly the idea. |
| 16:01 |
* mmorgan |
doesn't like that the hold gets cancelled after the maximum target attempts. |
| 16:02 |
mmorgan |
An action_trigger can send a cancellation notification, but cancellation still feels wrong. |
| 16:04 |
tsbere |
Hmmm |
| 16:05 |
Stompro |
mmorgan, I'm just starting the process, I don't think I'll be done in a week. |
| 16:05 |
tsbere |
Looks like if you set it to 0 (compared to not set at all) you get the "roam through libraries until you run out" behavior without the "cancel when you can't find it after X loops" bit |
| 16:06 |
jeff |
tsbere: and how does that differ from "not set at all"? |
| 16:06 |
Stompro |
tsbere, does it start the process over, or does the hold just go into limbo at that point. |
| 16:06 |
jeff |
tsbere: oh, it stops but doesn't cancel? |
| 16:06 |
tsbere |
jeff: Org unit setting doesn't exist *at all* (no entries) it doesn't touch this code. Org unit setting set to the number 0 and it doesn't run the cancel part. |
| 16:07 |
tsbere |
Basically, "no setting" is "don't run this code block". 0 is "unlimited loops" |
| 16:08 |
tsbere |
Or I could be reading the code wrong |
| 16:08 |
* tsbere |
only took a quick look |
| 16:08 |
tsbere |
we don't use the code, so I have never looked at it in depth |
| 16:08 |
* tsbere |
goes back to fighting with excel::writer::xlsx |
| 16:11 |
Stompro |
tsbere++ thanks again for taking a look. |
| 16:13 |
tsbere |
And now someone else tells me I previously told them it worked differently when set to 0 (or less). So I dunno. I probably mis-interpreted something but I have already closed the file. |
| 17:09 |
|
mmorgan left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:19 |
jeff |
looks like a problem downloading phantomjs. |
| 20:10 |
|
rlefaive joined #evergreen |
| 20:36 |
|
yboston joined #evergreen |
| 20:52 |
|
finnx joined #evergreen |
