Evergreen ILS Website

IRC log for #evergreen, 2015-08-24

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat