| Time |
Nick |
Message |
| 06:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 07:46 |
|
rlefaive joined #evergreen |
| 08:58 |
|
bos20k joined #evergreen |
| 09:07 |
|
Dyrcona joined #evergreen |
| 09:08 |
|
rjackson-home joined #evergreen |
| 09:22 |
|
yboston joined #evergreen |
| 09:27 |
|
kmlussier joined #evergreen |
| 09:42 |
|
terran joined #evergreen |
| 09:50 |
Dyrcona |
Some might find this interesting: https://blog.2ndquadrant.com/pg-phriday-postgres-zfs/ |
| 09:50 |
Dyrcona |
Makes me happier I choose ZFS on NVMe for our new db server. :) |
| 10:00 |
terran |
Good morning. Has anyone here seen Hatch working on a 32-bit version of Windows 7? I don't have access to a 32 bit Win 7 machine, but we're getting some reports from the field. |
| 10:11 |
Dyrcona |
terran: Are those reports negative? |
| 10:20 |
terran |
Dyrcona: Ha, yes. They're saying they're getting a white screen that they're unable to clear up with the instructions we've given them. I'm not 100% sure they have everything installed correctly, but since some of the same people have managed to get their 64 bit machines working, I'm just wondering if there is a 32 bit problem. |
| 10:29 |
|
jvwoolf joined #evergreen |
| 10:33 |
Dyrcona |
I thought I saw something about a white screen recently (not necessarily with Hatch), but I'm not finding it. |
| 10:33 |
Dyrcona |
It was either Hatch or the web client doing a white screen. |
| 10:33 |
|
Jboyer joined #evergreen |
| 10:34 |
Jboyer |
*poof* |
| 10:34 |
Jboyer |
I was just looking over the logs and noticed terran's Hatch question. |
| 10:35 |
|
Christineb joined #evergreen |
| 10:35 |
Jboyer |
Do you know if they're trying to install Hatch 0.1.3 or 0.1.5? Nothing else will work on 32 bit, and 0.1.5 fixes a permissions issue that may also help. |
| 10:36 |
csharp |
Jboyer: you mean 0.1.4? |
| 10:36 |
Jboyer |
I do. |
| 10:36 |
* csharp |
remembers a Monty Python-esque numbering confusion |
| 10:37 |
csharp |
"1, 2, 5. 3, sir!" |
| 10:37 |
Jboyer |
Seems like a good Four Yorkshiremen sketch could come out of it too with enough work. |
| 10:38 |
csharp |
Jboyer: we are having them install 0.1.4 - we have no idea what they *actually* have installed, of course - terran is asking for screenshots |
| 10:38 |
terran |
JBoyer: They've said they are, but I've asked for a screenshot. |
| 10:38 |
terran |
Jinx. |
| 10:38 |
csharp |
yeah, that^^ |
| 10:38 |
Jboyer |
When is your upgrade, anyway? tomorrow night, sooner? |
| 10:38 |
csharp |
tomorrow night |
| 10:38 |
Jboyer |
Good luck! |
| 10:38 |
terran |
Thanks! |
| 10:39 |
csharp |
Jboyer: thank you |
| 10:39 |
csharp |
we've prepared everyone as best we can for the web client - if it all falls apart it won't be for lack of effort :-) |
| 10:40 |
Dyrcona |
I've got a question not related to the current conversation. |
| 10:41 |
Jboyer |
Maybe with some more people using it more regularly we can smooth things out for some of our libraries. |
| 10:41 |
Dyrcona |
Has anyone seen the Circulation > Browse Hold Shelf load more slowly for one library versus another when the latter even has more items on the hold shelf? |
| 10:41 |
Jboyer |
we have 1 that has never used the XUL client so I've prioritized web fixes a LOT higher than I normally would. (we haven't moved them over to the XUL client because reasons...) |
| 10:42 |
Jboyer |
Dyrcona: I haven't heard of anything like it, no. I don't know how often that interface is used here. |
| 10:43 |
Dyrcona |
I've had a report of it yesterday, and I verified it myself. I'm told it's continuing today. |
| 10:43 |
jeff |
Dyrcona: xul client? how much more slowly? do you have a comparison for two libs that includes number of items on hold shelf and time to load for each? |
| 10:44 |
jeff |
Dyrcona: and for your verification, you were able to reproduce the issue from a workstation at a location where the primary difference was the library whose hold shelf you were browsing? |
| 10:44 |
Dyrcona |
jeff: Yes, and I could time it. Yesterday, library a had 120 items and took about a minute, library had 400 and took a few seconds. |
| 10:44 |
jeff |
(as opposed to each library loading from their location on their workstation, etc) |
| 10:44 |
Dyrcona |
Yeah, I verified the difference from my own workstation. |
| 10:44 |
jeff |
and since you were verifying, it's not something like each library measuring something different. |
| 10:45 |
jeff |
hrm. |
| 10:45 |
Dyrcona |
I'll try again today with a timer running. |
| 10:45 |
jeff |
was there a difference between the two in terms of number of items on the hold shelf that were cancelled, or shelf-expired, etc? |
| 10:46 |
Dyrcona |
I'll get those numbers. |
| 10:46 |
jeff |
i am intrigued but probably shouldn't wander too far down this rabbit hole today. maybe this weekend. :-) |
| 10:47 |
Dyrcona |
:) |
| 10:48 |
Dyrcona |
Took about 10 seconds for library B with 448 items. |
| 10:49 |
Dyrcona |
Library B has 2 Canceled and 446 Ready for pickup. |
| 10:50 |
Bmagic |
csharp: do you have something in place to kill long running queries. I was thinking last night that I should advise you to get something in place because of bug 1738488 |
| 10:50 |
pinesol_green |
Launchpad bug 1738488 in Evergreen 3.0 "Web client: patron billing history results in long running query" [Medium,Confirmed] https://launchpad.net/bugs/1738488 |
| 10:51 |
Bmagic |
If you don't have something to kill those off, your database could easily get clobbered once hundreds of staff are using the Web client. |
| 10:51 |
Bmagic |
of course, that's not the real* fix |
| 10:52 |
Dyrcona |
I've had to kill a number of those by hand in testing and training. |
| 10:52 |
Dyrcona |
I've noticed that they don't run for days with join_collapse_limit at 9 in production on 2.12. |
| 10:52 |
Dyrcona |
It's on the bug, but just throwing that out there. |
| 10:53 |
Dyrcona |
jeff: So, library A loaded in about 10 seconds, also. I'm not seeing a slow down today. |
| 10:53 |
jeff |
drat. |
| 10:54 |
Dyrcona |
Actually, more like 7 to 8 seconds. |
| 10:54 |
Dyrcona |
I didn't stop the stop watch soon enough, but waited until details filled in. |
| 10:54 |
jeff |
(or the opposite of drat, depending on your chosen perspective) |
| 10:54 |
Dyrcona |
yes. I'm still going look at hold status. That seems like a decent angle of attack. |
| 10:55 |
Dyrcona |
Library A has 272 this morning. |
| 10:58 |
csharp |
Bmagic: we have a cron that kills off long-running opac searches |
| 10:59 |
csharp |
I'll keep an eye out for long-running ones when we go live on Tuesday |
| 10:59 |
Bmagic |
csharp: you might want to expand that to look for queries that look like ~ SELECT "mp".amount, "mp".id, "mp".note, "mp".payment_ts, |
| 11:00 |
Dyrcona |
We've got a cron or nagios something that reports long running queries. |
| 11:00 |
Dyrcona |
Just reports them. |
| 11:00 |
Bmagic |
from what I've heard about your consortium and the sheer volume of requests, you might not have time to react! |
| 11:00 |
Dyrcona |
So, Library A also has 18 canceled items on the hold shelf. |
| 11:00 |
Dyrcona |
Thanks for the suggestions, jeff! |
| 11:01 |
Bmagic |
our CPU on db1 goes over 60% everyday (until those queries are killed) |
| 11:01 |
csharp |
Bmagic: whoa |
| 11:02 |
Bmagic |
csharp: right! I cannot understate how important this is and especially for you (most likely) |
| 11:02 |
csharp |
Bmagic: I really appreciate the heads up |
| 11:03 |
Bmagic |
other than that, the upgrade for us was very smooth |
| 11:03 |
csharp |
probably hogs DB backends until connections are exhausted |
| 11:04 |
csharp |
good argument for pg_bouncer or similar (which we don't have installed) |
| 11:04 |
Bmagic |
csharp: whichever solution you choose, but just be aware! |
| 11:05 |
Bmagic |
It was alarming for me (at first) |
| 11:05 |
* jeff |
absent-mindedly takes a sip of yesterday's coffee |
| 11:05 |
csharp |
lol |
| 11:05 |
csharp |
jeff: sorry :-/ |
| 11:05 |
* Bmagic |
watches jeff with a smirk |
| 11:06 |
Bmagic |
it could have been two day old coffee.... |
| 11:06 |
csharp |
@dessert jeff |
| 11:06 |
* pinesol_green |
grabs some Moon Pie and some RC Cola for jeff |
| 11:08 |
Dyrcona |
Hm... One of these canceled holds is from 2013! |
| 11:08 |
Dyrcona |
No, I take that back, a lot of them are and some from 2012.... |
| 11:09 |
Dyrcona |
Yeah, I noticed relatively high load on training and testing until those queries were killed, too. |
| 11:10 |
Dyrcona |
Setting join_coallapse_limit may help some. I did that for other reasons on production, but I think it is helping with the payment history queries. |
| 11:10 |
jeff |
Dyrcona: also, if you get to a point where you're suspecting the base query, -- yeah, I think you mostly already got where I was going. |
| 11:11 |
Dyrcona |
jeff: That query does some ridiculous joins, but I won't repeat too much of what was discussed in IRC recently and linked from the bug, IIRC. |
| 11:11 |
jeff |
That IDL view (which I think constitutes the base query for that interface) may suffer from the join-ordering issue. |
| 11:12 |
jeff |
wait, which bug -- oh, bug 1738488? |
| 11:12 |
pinesol_green |
Launchpad bug 1738488 in Evergreen 3.0 "Web client: patron billing history results in long running query" [Medium,Confirmed] https://launchpad.net/bugs/1738488 |
| 11:12 |
Dyrcona |
Heh. |
| 11:12 |
Dyrcona |
Yeah, I switch gears without warning. :) |
| 11:13 |
jeff |
fwiw, my "if you get to a point where you're suspecting the base query" line above was still regarding the previous gear -- the holdshelf issue you were looking at. :-) |
| 11:13 |
Dyrcona |
Something else I want to do on productions is turn off full_page_writes. ZFS pretty much guarantees that happens anyway and it should give a performance boost. |
| 11:14 |
Dyrcona |
jeff: I figured after the fact... :) |
| 11:14 |
Dyrcona |
I'm not suspecting anything except staff and/or network at Library A. |
| 11:17 |
Dyrcona |
Heh. Maybe someone was trying to view payments in the web staff client at the same time as someone else trying to browse the hold shelf? :) |
| 11:31 |
|
rlefaive joined #evergreen |
| 11:37 |
|
bshum joined #evergreen |
| 11:37 |
|
berick joined #evergreen |
| 11:38 |
|
maryj joined #evergreen |
| 11:39 |
|
JBoyer joined #evergreen |
| 12:10 |
|
JBoyer joined #evergreen |
| 12:15 |
|
khuckins joined #evergreen |
| 12:48 |
|
jihpringle joined #evergreen |
| 12:56 |
dbs |
5 is right out. |
| 13:02 |
csharp |
dbs++ |
| 13:15 |
Dyrcona |
:) |
| 13:50 |
kmlussier |
@dessert |
| 13:50 |
* pinesol_green |
grabs some Chocolate Eclairs for kmlussier |
| 13:50 |
pinesol_green |
[evergreen|Kyle Huckins] lp1742194 - Print Current Bills only printing circ bills - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=56bcda5> |
| 14:17 |
Dyrcona |
@weather |
| 14:17 |
pinesol_green |
Dyrcona: Methuen, MA :: Overcast :: 62F/17C | Friday: A steady rain. The rain will be heavy at times. High 61F. Winds S at 10 to 20 mph. Chance of rain 100%. Rainfall around a half an inch. Friday Night: Periods of rain. Low around 45F. Winds SSW at 10 to 15 mph. Chance of rain 100%. Rainfall may reach one inch. Rain and snow melt may lead to flooding. |
| 14:18 |
Dyrcona |
Crazy.... |
| 14:21 |
terran |
We might get snow flurries. |
| 14:25 |
kmlussier |
Dyrcona: Just wait until tomorrow when temps drop and it all turns to ice. |
| 14:26 |
Dyrcona |
Yeah, Accuweather says high tomorrow 53 degrees Fahrenheit with a low of 13... |
| 14:55 |
troy__ |
if midwest, we all know midwest doesn't play by any rules :) |
| 14:56 |
troy__ |
55 yesterday for MI was well out of the norm, but today 2-5 inches of snow |
| 14:59 |
|
rlefaive joined #evergreen |
| 15:33 |
|
rlefaive joined #evergreen |
| 15:39 |
troy__ |
question: in a custom script we're calling open-ils.circ.renew, which uses our global admin user to auth (no workstation). this, however, is ignoring our circ policies for renewal and renewing all items for the same periods. is there a setting to fix this so it follows our item renewal policies? is there a way to set a standard circ lib so that renewals get the proper renewal time? |
| 15:40 |
Dyrcona |
troy__: Easiest way is to use a user account with a workstation. |
| 15:45 |
troy__ |
no way to just set a global for org_unit default? |
| 15:46 |
Dyrcona |
No. There's no global or org_unit setting. |
| 15:47 |
Dyrcona |
How are you doing the renewal? Are you using a circ id or a circ object? (IIRC, both work....) |
| 15:49 |
Dyrcona |
You could probably get really down and dirty and instantiate an OpenILS::Circ::Circulate::Circulator object and set the circ_lib and other fields and then call do_renew(). |
| 15:50 |
troy__ |
circ id |
| 15:50 |
troy__ |
we're doing this via php |
| 15:51 |
Dyrcona |
Then, you want to stick the open-ils.circ calls. I really wouldn't recommend getting dirty unless you're really comfortable with the Perl code. |
| 15:52 |
troy__ |
yea, only one of us is familiar with perl |
| 15:52 |
troy__ |
rest of us can just read |
| 15:52 |
phasefx |
troy__: any reason to not use a workstation with the login? |
| 15:53 |
Dyrcona |
Well, you'd really want to be familiar with Circulate.pm, not just Perl in general. :) |
| 15:53 |
troy__ |
i've already spent hours of my life reading through that file :P |
| 15:53 |
Dyrcona |
I'm looking at the run_method to see if you can use a circ object, and if you can set the circ_lib somehow. |
| 15:54 |
phasefx |
alternately, you could probably change the home_ou of the admin user, I think that might get used in leu of workstation_lib if there is no workstation, for circ stuff |
| 15:54 |
troy__ |
phasefx: i'm still learning a lot of this. can you set a default workstation for a user? |
| 15:54 |
phasefx |
workstation would be better, though |
| 15:55 |
phasefx |
troy__: whatever you do when you get an authtoken, you should be able to specify a workstation in that same step |
| 15:55 |
Dyrcona |
phasefx is correct, however..... you can force a circ_lib, I think. |
| 15:55 |
phasefx |
but I'm not familiar with any php libraries for this |
| 15:56 |
troy__ |
we built our own |
| 15:56 |
phasefx |
better to do the right thing up front than play whack-a-mole, IMO |
| 15:56 |
Dyrcona |
If your args look like: {'circ': <circ_id:int>, 'circ_lib': <org_unit_id:int>} in JSON, it should do the renewal at the specified circ_lib. |
| 15:57 |
troy__ |
so can open-ils.circ.renew take that extra param? |
| 15:58 |
Dyrcona |
But, yeah, when I wrote a script to autorenew circulations, I used an account that logged in with a specific workstation to get certain rules. |
| 15:58 |
troy__ |
('open-ils.circ.renew', [$token, ['patron_id' => $pnum, 'copyid' => $copyid]]); |
| 15:58 |
Dyrcona |
troy_: Yes. |
| 15:59 |
Dyrcona |
Renew goes through run_method, and the args hash is passed to the circulator, so you can set some extra Circulator fields in the args hash. |
| 16:00 |
troy__ |
thank you so much |
| 16:00 |
troy__ |
my basic perl self only looked at notes for what it could take |
| 16:00 |
troy__ |
Dyrcona++ |
| 16:00 |
troy__ |
phasefx++ |
| 16:01 |
Dyrcona |
Caveat is, I've not actually tried passing circ_lib, but it looks like it should work from the code, and I've passed similar arguments before, like opac_renewal, so... |
| 16:01 |
troy__ |
well we're gonna find out! |
| 16:01 |
troy__ |
will make patrons much happier if this works |
| 16:05 |
Dyrcona |
troy__: Not sure what you're doing, but it sounds like an auto-renew script? You might want to try the opac_renewal option and see how that works for you. |
| 16:06 |
troy__ |
we built an api for our website |
| 16:06 |
Dyrcona |
That *should* make it look more or less like a patron renewed it through the OPAC. |
| 16:06 |
troy__ |
so patrons can hit renew on their items |
| 16:07 |
Dyrcona |
If you're running the server with Apache, you can use an auth module to have patrons login first, and you might be able to use their authtoken. |
| 16:08 |
* Dyrcona |
searches config for the module name. |
| 16:09 |
Dyrcona |
Y |
| 16:09 |
Dyrcona |
OpenILS::WWW::Proxy::Authen |
| 16:10 |
Dyrcona |
It requires ModPerl on the server and might require some bits of OpenSRF and Evergreen. |
| 16:11 |
troy__ |
our api server is on nginx, but our evg server is apache |
| 16:11 |
Dyrcona |
Yeah, it requires OpenSRF and the ability to talk to the public router, at least. |
| 16:11 |
troy__ |
k, we'll dig more |
| 16:11 |
Dyrcona |
Well, then, it won't work for you. |
| 16:12 |
Dyrcona |
I've used it before for a thing for staff. |
| 16:14 |
* Dyrcona |
recalls getting the nutty idea that an OAuth provider would be a cool thing to have some time ago. :) |
| 16:14 |
Dyrcona |
OAuth2 at any rate. |
| 16:16 |
troy__ |
i greatly appreciate your help Dyrcona |
| 16:16 |
Dyrcona |
YW. |
| 16:16 |
troy__ |
Dyrcona++ |
| 16:16 |
troy__ |
Dyrcona++ |
| 16:25 |
kmlussier |
@praise Dyrcona |
| 16:25 |
* pinesol_green |
Dyrcona LOVES the RESISTANCE! |
| 16:29 |
Dyrcona |
heh |
| 16:54 |
kmlussier |
OK, I'm out. Have a nice weekend everyone! |
| 17:18 |
|
bshum joined #evergreen |
| 17:26 |
|
jvwoolf left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 18:59 |
|
alynn26_ joined #evergreen |
| 19:05 |
|
alynn26_ joined #evergreen |
