| Time |
Nick |
Message |
| 01:16 |
|
Mark__T joined #evergreen |
| 05:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:18 |
|
mrpeters joined #evergreen |
| 07:36 |
|
sarabee joined #evergreen |
| 07:37 |
|
rjackson_isl joined #evergreen |
| 07:50 |
|
rlefaive joined #evergreen |
| 07:51 |
|
akilsdonk joined #evergreen |
| 08:11 |
|
ericar joined #evergreen |
| 08:11 |
|
Shae joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 09:03 |
|
mmorgan joined #evergreen |
| 09:04 |
|
maryj joined #evergreen |
| 09:05 |
|
rlefaive joined #evergreen |
| 09:10 |
|
collum joined #evergreen |
| 09:22 |
|
RoganH joined #evergreen |
| 09:24 |
|
yboston joined #evergreen |
| 09:48 |
|
krvmga_ joined #evergreen |
| 09:56 |
krvmga |
is anyone actively working on syrup? |
| 09:57 |
RoganH |
kmlussier did a fair bit of work with it a few years ago but I don't know how current that is |
| 09:58 |
mmorgan |
krvmga: we are actively *using* syrup. |
| 09:58 |
* krvmga |
is looking forward to talking with mmorgan on friday. :) |
| 09:59 |
krvmga |
we're using it in C/W MARS and responsibility for it has recently devolved upon me. |
| 09:59 |
mmorgan |
...and others :) |
| 09:59 |
krvmga |
:) |
| 10:04 |
Dyrcona |
artunit is, IIRC, the main developer behind it. |
| 10:04 |
Stompro |
What is syrup, it's a little hard to google that... |
| 10:05 |
dbs |
gfawcett did a lot of the coding for artunit |
| 10:05 |
dbs |
It's an e-reserves system that integrates with Evergreen, Koha, etc |
| 10:05 |
dbs |
http://git.evergreen-ils.org/?p=Syrup.git;a=summary |
| 10:05 |
krvmga_ |
it looked like nothing much had been done for years |
| 10:06 |
Stompro |
Hehe, the first result after "Syrup e-reserves" -> "Why Does Canada Have a Strategic Maple Syrup Reserve? " |
| 10:06 |
|
TaraC joined #evergreen |
| 10:06 |
Dyrcona |
Stompro: Several million gallons were stolen from the strategic maple syrup reserve a year or so ago. |
| 10:06 |
RoganH |
Is Canada abusing it's geopolitical syrup power like Russia does with natural gas? |
| 10:07 |
krvmga_ |
we're running python 2.6 on our server and the current version is 3.4.2. i'm worried about backward compatability if we upgrade. |
| 10:07 |
Dyrcona |
But, on a completely unrelated note, I think I just fixed my mouse by hurling it across the office. |
| 10:07 |
RoganH |
Dyrcona++ |
| 10:07 |
Stompro |
Dyrcona, I remember hearing about that. |
| 10:08 |
mmorgan |
Stompro: Here's one of our syrup sites: http://reserves.noblenet.org/ssu/browse/ |
| 10:08 |
krvmga_ |
compatability -> compatibility |
| 10:08 |
RoganH |
repair skills honed on old vacuum tube TVs still have application |
| 10:08 |
krvmga_ |
Dyrcona: i think i read that fix in the appendix to the mouse manual |
| 10:09 |
jeff |
krvmga_: because of the fact that python3 will not run every python2 app out of the box, you're likely to have python2 available for a while. |
| 10:09 |
Dyrcona |
It kept double clicking when I only single clicked, so I hurled it in frustration thinking it would break. |
| 10:09 |
jeff |
Dyrcona: just another form of "percussive maintenance" |
| 10:09 |
krvmga_ |
here's one of our syrup sites: http://rb.cwmars.org/bcc/browse/ |
| 10:09 |
Dyrcona |
After putting the batteries back in, it appears to be fixed. |
| 10:10 |
krvmga_ |
jeff: i figured as much. thanks. |
| 10:10 |
Dyrcona |
Spring must have been out of alignment.... |
| 10:10 |
Dyrcona |
"If brute force doesn't work, you aren't using enough." |
| 10:11 |
dbs |
krvmga_: python 2.x is considered a separate language from python 3.x, so don't worry about that; python 2.7.x will be around for a long time |
| 10:11 |
dbs |
like jeff said |
| 10:11 |
Stompro |
krvmga, I just get a big ol' error report when I visited your site. |
| 10:11 |
Dyrcona |
It's frustrating when you click the icon to change a milestone, the mouse double-clicks and a milestone is chosen seemingly at random. |
| 10:12 |
Dyrcona |
And, it is possible to write stuff that works in both 2.7 and 3.4, mostly using a lot of try blocks. |
| 10:12 |
krvmga_ |
Stompro: yes, thanks for letting me know. that's one of the reasons i'm talking about this here now. i'm getting these odd intermittent errors |
| 10:12 |
dbs |
krvmga_: also, latest commits in Syrup master repository show 12 months ago from artunit |
| 10:12 |
dbs |
Dyrcona: or the "six" module for a compatibility layer |
| 10:12 |
krvmga_ |
dbs: i have to check them out. thanks. |
| 10:12 |
Dyrcona |
yeah, that, too. |
| 10:13 |
Dyrcona |
artunit artunit artunit # maybe if we say his name enough times..... :) |
| 10:13 |
Stompro |
krvmga, seems to be working now. |
| 10:13 |
krvmga_ |
Stompro: timeouts and errors that look like a variable isn't being declared before being called |
| 10:13 |
dbwells |
We've been using Syrup for about a year now. We hacked a few pieces of it, mostly for local performance issues, but other than that, it has worked pretty well. We also upgraded from Python 2.6 to 2.7 earlier this week, and haven't seen any Syrup problems from that. |
| 10:14 |
* krvmga |
got rid of the other login. |
| 10:14 |
krvmga |
up till now, we haven't had many problems with it. |
| 10:15 |
krvmga |
Stompro: you must have gotten the timeout error. a refresh usually clears that. but that being said, you shouldn't be getting the timeout error to begin with. |
| 10:16 |
Stompro |
krvmga, The second error was the timeout error, the first error was something else. |
| 10:16 |
dbwells |
As part of the upgrade, we did have one issue with a newer version of the ply module. 3.6 gave Syrup issues, but going back to 3.4 took care of it. |
| 10:18 |
dbwells |
It seemed like the problem came from PyZ3950 (version 2.04), but I didn't have time to dig further than that yet. |
| 10:18 |
|
rlefaive joined #evergreen |
| 10:21 |
|
jwoodard joined #evergreen |
| 10:22 |
|
bmills joined #evergreen |
| 10:24 |
bshum |
Dyrcona: Remind me to get you the bug maintenance credentials (once I find them myself) |
| 10:25 |
Dyrcona |
bshum: OK. As you know, I was trying to do that via a Python script, but gave up after an hour of tinkering and moved the bugs by hand. |
| 10:25 |
Dyrcona |
Launchpadlib api changed and I couldn't figure out how to alter the bugs. |
| 10:25 |
bshum |
Dyrcona: Sure, I just remember being asked to use the bug maintenance account when handling lots of bug target shifts, to avoid spamming everyone. |
| 10:25 |
bshum |
But I can never quite remember the password for it. |
| 10:26 |
Dyrcona |
bshum: Yep. I knew about that, but I was never given the password, so. |
| 10:27 |
dbs |
heh |
| 10:27 |
Dyrcona |
I'm working on some communications to send out later today, but as those who get the bug email may have surmised, there will be no 2.9-alpha. |
| 10:28 |
bshum |
Dyrcona: In hindsight then |
| 10:28 |
bshum |
We could have just renamed the 2.9-alpha milestone |
| 10:28 |
bshum |
To 2.9-beta |
| 10:28 |
bshum |
And skipped moving around bug targets. |
| 10:29 |
Dyrcona |
Oh well. |
| 10:29 |
* dbs |
wonders how gogs.io is looking these days :) |
| 10:30 |
* Dyrcona |
isn't always the sharpest tool in the shed. |
| 10:31 |
berick |
Dyrcona: but you are using the correct amount of brute force |
| 10:31 |
Dyrcona |
berick++ |
| 10:32 |
Dyrcona |
Is it just me, or has this been a frustrating half of a week for others, too? |
| 10:33 |
bshum |
I can't remember what day it is. |
| 10:33 |
berick |
dbs: have you tried gogs? |
| 10:33 |
bshum |
So yes. |
| 10:34 |
|
bshum left #evergreen |
| 10:34 |
|
bshum joined #evergreen |
| 10:34 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 10:34 |
bshum |
Well that was the wrong button to hit... |
| 10:34 |
mmorgan |
Today started out being a Bad Technology Day, but fingers crossed it's getting better. |
| 10:37 |
Dyrcona |
mmorgan: Throw it across the room. Worked for me. :) |
| 10:38 |
mmorgan |
Some stuff's a bit heavy, though ;-). |
| 10:39 |
Dyrcona |
yeah |
| 10:42 |
dbs |
berick: nope. supposedly our uni is rolling out a Jira implementation so I held off on moving from our own Trac to anything else. Gogs has 314 open issues, 716 closed on https://github.com/gogits/gogs/issues |
| 10:42 |
dbs |
(and hey, not self-hosted? heh) |
| 10:47 |
Stompro |
Does anyone else see a high number of orphan sockets on their system like I was seeing in bug 1478123? "lsof | grep " sock " | wc -l" |
| 10:47 |
pinesol_green |
Launchpad bug 1478123 in Evergreen "Missing close() after shutdown() in EGCatloader/Record.pm FD Leak" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1478123 |
| 10:50 |
bshum |
Stompro: Define " a high number" |
| 10:50 |
dbs |
Stompro: 0 here |
| 10:51 |
* dbs |
immediately wonders if it's related to a particular added content provider that we're not using |
| 10:51 |
Stompro |
After the issue is fixed, I see 2 per apache process + ~7. Before several thousands after a few days. |
| 10:51 |
Stompro |
Using openlibrary for cover art only. |
| 10:52 |
Stompro |
Well, I guess not cover art only, .. but using openlibary is the key part. |
| 10:52 |
bshum |
Stompro: Well we haven't applied your fix to our systems yet. |
| 10:53 |
Stompro |
Yah, I'm just wondering if it is just something with my config, or if it just doesn't pose a problem to others, even if the symptoms are there. |
| 10:53 |
berick |
dbs: i chuckled at the github hosting too :) |
| 10:53 |
bshum |
But fwiw, running lsof | grep " sock " | wc -l |
| 10:53 |
bshum |
That shows me something between 150-200 |
| 10:53 |
berick |
some day, perhaps |
| 10:53 |
bshum |
For each of our apache heads |
| 10:53 |
bshum |
Not all from opensrf user though, that's total. |
| 10:54 |
* bshum |
supposes he could run that as opensrf to see how many for that alone. |
| 10:55 |
bshum |
Fwiw, we use Syndetics for our added content. |
| 10:56 |
Stompro |
bshum, Hmm, I wonder why the missing close is just a problem for us? 150-200 seems fine, not a problem. Do you restart apache on a schedule? What is your maxrequests per child set to? |
| 10:57 |
|
akilsdonk joined #evergreen |
| 10:57 |
bshum |
Stompro: We do not restart apache, unless we're pulling an application server out of rotation to apply patches, etc. |
| 10:58 |
bshum |
Our apache config shows maxrequestsperchild to 10000 |
| 10:58 |
Stompro |
I saw the problem using both content cafe and open library providers, on both Debian Jessie and Wheezy. |
| 10:59 |
dbs |
weird. I wonder how we're at 0. |
| 10:59 |
* dbs |
checks to ensure they're actually running :) |
| 11:01 |
Stompro |
dbs, I think that two of them per apache process are caused by me not having ipv6 setup, apache seems to assign a socket for ipv6 at launch, but then never binds it because it doesn't need to listen on an ipv6 address. So if you are using ipv6 then those probably are not there. |
| 11:03 |
Stompro |
I'm wondering how that bug ever gets confirmed/signedoff if it doesn't effect anyone else? |
| 11:04 |
bshum |
Stompro: Well, since gmcharlt indicated on the email thread he was interested in your patches, I'd pick on him :) |
| 11:04 |
Stompro |
bshum++ dbs++ thanks for checking your systems. |
| 11:04 |
* bshum |
throws gmcharlt under the bus |
| 11:04 |
bshum |
(with love) |
| 11:05 |
mmorgan |
Stompro: Our 4 bricks were all restarted this morning. I'm getting 224, 219, 251, 223 when I run your command as root. |
| 11:06 |
Stompro |
On the other hand, it isn't that big of a deal to add that locally, it is just a couple lines that probably won't change much over the years. The Beauty of evergreen. |
| 11:07 |
dbs |
Stompro: we certainly have ipv6 |
| 11:07 |
dbs |
sitka++ |
| 11:07 |
|
eby joined #evergreen |
| 11:10 |
Stompro |
mmorgan++, thanks. Would you mind checking again in a few hours and see if it goes up significantly? Loading a record detail page is what caused the leak for me. Increased it by ~5 each reload. |
| 11:12 |
mmorgan |
So what happens ultimately if we have the problem and it goes unchecked? I am just wondering if we've been having this issue all along and not recognizing it as a problem. |
| 11:14 |
Stompro |
mmorgan, in our system it was a resource starvation issue, apache wouldn't be able to assign new sockets to new connections... but that is just because the container software we use limits tcp sockets per VM, and counted them as active TCP sockets. It also takes up a file descriptor, but those limits are usually extremly high. |
| 11:15 |
berick |
we're in the 150 to 200 range. we recycle apache workers a little more aggressively, though, after 5k requests. |
| 11:15 |
mmorgan |
ok, I'll recheck in a few hours. We use Content Cafe, FWIW. |
| 11:15 |
dbs |
100k here |
| 11:16 |
dbs |
MaxRequestsPerChild 100k, that is |
| 11:18 |
berick |
bold |
| 11:18 |
Stompro |
confident |
| 11:19 |
jeff |
well-rounded |
| 11:19 |
jeff |
with notes of buttersweet chocolate |
| 11:19 |
jeff |
and a hint of citrus |
| 11:19 |
jeff |
no, wait. that's what my coffee package says. nevermind. |
| 11:20 |
mmorgan |
jeff: sounds like good coffee!! |
| 11:20 |
jeff |
and yes, s/buttersweet/bittersweet/ |
| 11:24 |
Bmagic |
I am interested in speeding up our search results. I started parsing the logs for a single search result in the OPAC. It generated 387 log lines. Looking for "Message processing duration" I find that my top time is results from [INFO:23123:Biblio.pm:964:xxxx] compiled search is ...... |
| 11:24 |
Bmagic |
taking 4.111 seconds |
| 11:25 |
Bmagic |
metabib.pm:2927:14393923242307611] pref_ou takes 2.9 seconds |
| 11:25 |
Bmagic |
CALL: open-ils.cstore open-ils.cstore.direct.config.coded_value_map.search.atomic is another .5 seconds |
| 11:26 |
Bmagic |
Anyone have a suggestion on cutting these down? |
| 11:27 |
berick |
i think the pref_ou bit is part of the search |
| 11:27 |
berick |
it's not an additional 2.9 seconds of stuff |
| 11:28 |
berick |
Bmagic: what are the parameters to the open-ils.cstore.direct.config.coded_value_map.search.atomic call? |
| 11:28 |
Bmagic |
I see. Still though, I compare our response times to other evergreen libraries and we pale in comparison |
| 11:28 |
Bmagic |
{"id":{"!=":null}} |
| 11:29 |
berick |
Bmagic: ok, well, those should be cached by the tpac. subsequent searches should not be taking that hit. good to confirm, though |
| 11:29 |
berick |
well, cached per process, so there's a hit w/ each new apache worker process |
| 11:30 |
Bmagic |
funny enough, this sample was "cached" meaning that I had already performed the same search seconds before I captured the logs |
| 11:30 |
jeff |
sure, but this time you likely hit a different apache backend. |
| 11:30 |
berick |
what jeff said |
| 11:30 |
jeff |
that had not had cause to fetch and cache the ccvm list yet. |
| 11:30 |
Bmagic |
right on |
| 11:31 |
Bmagic |
it's taking upwards of 7 seconds for search results to return |
| 11:31 |
Bmagic |
and other OPAC's in the world, I find it's returning in less than 2 seconds |
| 11:31 |
berick |
if the exact same search was run, it really should have been faster. the search itself should have been cached |
| 11:32 |
berick |
really, the pref_ou bits you pasted should not have even happened |
| 11:32 |
berick |
assuming the /exact same/ search |
| 11:32 |
Bmagic |
Im pretty sure we have something wrong somewhere |
| 11:33 |
Bmagic |
we just doubled the memory in our DB server, our total size on disk is 130GB on the DB server. It has 224GB of memory |
| 11:33 |
hopkinsju |
224GB! |
| 11:34 |
bshum |
Yeah, but is your postgresql.conf tuned to use it? :) |
| 11:34 |
Bmagic |
pgtune |
| 11:34 |
bshum |
pgtune is kind of evil. |
| 11:34 |
bshum |
Depending on which version of PostgreSQL you're using. |
| 11:34 |
Bmagic |
9.2 |
| 11:34 |
bshum |
Or so we've found in our travels |
| 11:34 |
berick |
Bmagic: how much memory is memcache using compared to its configured max? |
| 11:35 |
Bmagic |
hmm, I havn't looked at memcache |
| 11:35 |
Bmagic |
would that be the -m switch? |
| 11:35 |
bshum |
Yes |
| 11:35 |
Bmagic |
-m 4096 |
| 11:36 |
dbs |
yikes |
| 11:36 |
bshum |
Bmagic: That's not too bad. I think that's what I configured ours to. |
| 11:37 |
bshum |
Better than the default 64 MB anyways :) |
| 11:37 |
berick |
assuming the machine it's on has > 4096M |
| 11:37 |
dbs |
we're at a tiny little -m 256 |
| 11:37 |
hopkinsju |
224G on that server |
| 11:37 |
hopkinsju |
That is, memcache is running on our primary DB |
| 11:37 |
|
mllewellyn joined #evergreen |
| 11:37 |
Bmagic |
there are 6 memcached processes running reporting 1.4g RES memory each |
| 11:38 |
bshum |
Each? |
| 11:38 |
|
Christineb_away joined #evergreen |
| 11:38 |
Bmagic |
if I'm interpreting top correctly |
| 11:39 |
Bmagic |
1595m virtual mem each |
| 11:39 |
* bshum |
only has one memcache process, so isn't sure if that's "normal" |
| 11:39 |
berick |
yeah, i've only ever seen 1 memcached process running |
| 11:40 |
Bmagic |
there is only one process running on ps, however top has it split up in the display |
| 11:40 |
jeff |
you may be looking at threads. |
| 11:40 |
Bmagic |
threads |
| 11:40 |
berick |
ah |
| 11:40 |
berick |
so, 1.4G is OK then |
| 11:41 |
Bmagic |
so, a great deal of the time I am waiting for results is this 4.111 seconds |
| 11:42 |
berick |
Bmagic: so, you run the same search multiple times and that 4+ seconds is always there? |
| 11:42 |
Bmagic |
let me try again |
| 11:42 |
Bmagic |
might be a difference between clicking the search button and hard refreshing the browser? |
| 11:43 |
jeff |
so, a refresh of the browser is likely going to be most assuredly exact, but in theory both should be the same. |
| 11:44 |
bshum |
One time I put our entire DB on a laptop SSD, and the slowest thing that happened was search results taking longer to show up cause the added content grabbing for cover art. |
| 11:44 |
jeff |
there's potential for us to be trimming params or re-ordering params in a way that makes the two distinct, though. |
| 11:45 |
berick |
jeff: i think the search cache code sorts the param keys before hashing |
| 11:45 |
bshum |
Bmagic: You don't have any other scripts on the page that link to external systems, right? Google Analytics, or... hmm |
| 11:45 |
berick |
may not be doing so deeply, though |
| 11:45 |
bshum |
Just wondering if maybe there's slowdown on the networking between your client, your server, and third-parites. |
| 11:45 |
bshum |
*parties |
| 11:45 |
bshum |
I've seen that happen sometimes where DNS lookups go slowly and cause... issues. |
| 11:45 |
jeff |
berick: ah, good. logical, even! (sorting the params) |
| 11:46 |
Stompro |
Bmagic, how are your page loads for other types of results. How long does it take to load a record detail page? |
| 11:46 |
berick |
at debug level, you can see in the logs if a search is loaded from cache, fyi |
| 11:46 |
Bmagic |
this test still has CALL: open-ils.cstore open-ils.cstore.direct.config.coded_value_map.search.atomic {"id":{"!=":null}} |
| 11:46 |
Bmagic |
and it was for sure the exact same search |
| 11:47 |
berick |
Bmagic: you may have to run multiples searches before the coded_value_map call goes away |
| 11:47 |
berick |
depends on the number of apache backends you have running |
| 11:47 |
Bmagic |
my next step was to turn up the logging, however, it looks like I am getting the information I need with regards to time taken for each step |
| 11:47 |
bshum |
For the logs: postgresql.conf and pgtune; the issue I remember is that work_mem and shared_buffers gets set to something really high if it's available. |
| 11:47 |
bshum |
But what we found is that having those set too high causes... issues |
| 11:48 |
Bmagic |
the big 4 second hit didnt exist this time |
| 11:48 |
bshum |
With certain queries |
| 11:48 |
bshum |
Last hackaway, miker gave us some hints on that while we were troubleshooting slowness with search |
| 11:48 |
bshum |
And we lowered our values significantly |
| 11:48 |
Bmagic |
INFO:22960:Biblio.pm:9 Message processing duration: 0.027 |
| 11:49 |
Bmagic |
interesting |
| 11:49 |
Bmagic |
about the postgres tuning |
| 11:49 |
berick |
Bmagic: ok, good, sounds like search caching is working |
| 11:49 |
Stompro |
Are these long searches causing sql qeries that are being logged in your postgresql logs? |
| 11:50 |
bshum |
Yeah, for our DB (192 GB of RAM), pgtune suggested work_mem = 1152MB and shared_buffers = 44 GB. But we changed that down to like work_mem = 128 MB and shared_buffers = 8GB |
| 11:50 |
Bmagic |
right now, I am looking at the app server logs, I havn't dug into the postgres logs just yet |
| 11:50 |
Bmagic |
I thought I would ask someone who has done this sort of thing before |
| 11:51 |
bshum |
I think there's a thread about it somewhere. But basically pgtune for PG 9.1+ is... untrustworthy. For some of these values. |
| 11:51 |
Bmagic |
maintenance_work_mem = 1GB effective_cache_size = 160GB work_mem = 224MB wal_buffers = 8MB shared_buffers = 52GB |
| 11:52 |
Bmagic |
what are you using for max connections? |
| 11:52 |
bshum |
Bmagic: I'm terrible, set ours to crazy stuff like 1000 (though past logging shows we usually don't exceed 250-300 usually). |
| 11:52 |
bshum |
Bmagic: I should be using some sort of connection pooling |
| 11:53 |
|
rlefaive joined #evergreen |
| 11:54 |
bshum |
Bmagic: Some thoughts on pgtune/pg9.3 anyways - http://postgresql.nabble.com/pgtune-configurations-with-9-3-td5824990.html |
| 11:54 |
hopkinsju |
Completely unrelated... Does anyone have an oils_yaz.conf that *actually* specifies this listener directive? |
| 11:55 |
bshum |
In that thread, they discuss the theoretical limit of shared_buffers being 8 GB |
| 11:55 |
bshum |
And it has something to do with toppling your DB server. I didn't get to read all the finer print and all the associated threads yet. |
| 11:57 |
* bshum |
is not a PG expert though, so will defer to others who know more on the subject matter. |
| 11:59 |
bshum |
Bmagic: Which version of Evergreen are you guys running again? |
| 12:00 |
Bmagic |
2.8.2 |
| 12:01 |
bshum |
Okay, just checking. |
| 12:03 |
|
jonadab_znc joined #evergreen |
| 12:03 |
Bmagic |
how about workers in the opensrf.xml ? we have max_children = 45 and max_spare_children = 5 |
| 12:03 |
Bmagic |
is that low? |
| 12:03 |
jeff |
oh hey, i forgot that we had written a report that incorporates patron address alerts logic. |
| 12:04 |
Bmagic |
would that impact response speed? |
| 12:10 |
Bmagic |
bshum: I think there is a strong case there for keeping shared_buffers at 8GB |
| 12:25 |
krvmga |
i noticed our Syrup server is running evergreen 2.3.3 and our regular production servers are running 2.7. since the two systems need to interact, does anyone see this as a problem? |
| 12:49 |
Dyrcona |
krvmga: It could be. I'm pretty sure there were some incompatible IDL changes from 2.3 to 2.7. |
| 12:50 |
krvmga |
i've tried moving the latest IDL file into the 2.3 installation. it didn't blow up. at least that's something. |
| 12:51 |
Dyrcona |
You should still upgrade the code, 'cause 2.3 doesn't know about any new fields, etc. |
| 12:51 |
krvmga |
Dyrcona: yeah, i think that's what we'll need to do. |
| 12:51 |
krvmga |
thx |
| 12:51 |
Dyrcona |
Moving the IDL might prevent some problems, but won't prevent them all. |
| 12:52 |
jeff |
i've not looked at syrup in a while, but i'm not sure i follow how there's an evergreen install on the syrup server and somehow things are talking to a different evergreen system. |
| 12:53 |
Dyrcona |
jeff: I imagine it is mostly a client installation, but could be mistaken. |
| 12:55 |
krvmga |
have to run. bbl. |
| 13:00 |
dbs |
jeff: you need at least the OpenSRF and Evergreen python libraries, IIRC |
| 13:01 |
* dbs |
has vague memories of encouraging gfawcett to fetch and cache IDL at runtime instead of hardcoding anything locally, but that was ages ago |
| 13:02 |
dbs |
fwiw, my LDAP-sync python script fetches and parses the live IDL from the web server on each run |
| 13:03 |
|
rlefaive joined #evergreen |
| 13:06 |
|
jihpringle joined #evergreen |
| 13:23 |
|
maryj joined #evergreen |
| 13:23 |
|
akilsdonk joined #evergreen |
| 13:40 |
jboyer-isl |
hopkinsju: I don't know if you've found it anywhere or not, but this is how we set up our listener in oils_yaz.xml: <listen id="public">tcp:@:2100</listen> This is a child of the root <yazgfs> element, and our firewall redirects incoming port 210 to 2100 so yaz doesn't need to run as root. |
| 13:49 |
dbs |
hopkinsju: we use "authbind" to run simpleserver and bind to port 210 using an otherwise unprivileged user |
| 13:50 |
dbs |
authbind simple2zoom -c conifer.conf -- -f conifer-format.conf 0.0.0.0:210 0.0.0.0:2210 |
| 13:56 |
* jeff |
does the "python 3 or not?" thing for a new project |
| 13:58 |
ldw |
I am trying to link to the Raw IRC logs for this months developers' meeting. The links look like this: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-07-01-15.02.log.html. However, when I update the link to 2015-08-05, I get a 404. Does someone have to create the Raw IRC log on the evergreen-ils.org server? |
| 13:59 |
jeff |
ldw: you probably want http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-07-01-15.02.log.txt |
| 13:59 |
jeff |
oh. 2015-08-05? |
| 13:59 |
jeff |
http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-08-05-15.07.log.txt -- similar pattern |
| 13:59 |
jeff |
ldw: the directory is indexed: http://evergreen-ils.org/meetings/evergreen/2015/ |
| 13:59 |
jeff |
rather, doesn't have indexes disabled. |
| 13:59 |
|
rlefaive joined #evergreen |
| 14:00 |
jeff |
ldw: does that help? |
| 14:00 |
ldw |
jeff: thank you, that helps exactly as needed. |
| 14:00 |
jeff |
catching up on that meeting is something i need to do tonight, since i was pretty much offline that entire week. |
| 14:01 |
* Dyrcona |
does python 3 unless he's using a module that doesn't have a python 3 version available. |
| 14:01 |
Dyrcona |
dunno if that helps, jeff |
| 14:01 |
ldw |
jeff: I have some todo's to follow up with you as well. Let me know when you have spare cycle.s |
| 14:17 |
|
gsams joined #evergreen |
| 14:18 |
hopkinsju |
jboyer-isl, dbs: Thanks guys. Thanks helps a lot! |
| 14:20 |
|
gsams joined #evergreen |
| 14:21 |
|
jlitrell joined #evergreen |
| 14:31 |
|
ericar_ joined #evergreen |
| 14:36 |
|
jihpringle joined #evergreen |
| 15:26 |
Bmagic |
Something interesting: on 2.7 we were able to click the "edit" button from the OPAC view and get the volume editor for the specific item, change the call number, then get the copy editor and change something and modify copies. Now with 2.8.2, there is an error "item with the same barcode exists" |
| 15:27 |
Bmagic |
tracking it down in the code, volume_copy_creator.js - seems like the copy id isn't getting passed from one interface to the next |
| 15:28 |
Bmagic |
anyone else have this? |
| 15:34 |
jeff |
berick++ for pysip2 |
| 15:36 |
berick |
jeff++ for being the first to try it besides me |
| 15:36 |
mmorgan |
Bmagic: We use the unified editor systemwide, so we don't see this workflow. |
| 15:38 |
Bmagic |
mmorgan: yeah, I was going to suggest that but we have bad history with that editor |
| 15:38 |
mmorgan |
However, I flipped the option on our training server and don't see the same thing you describe. |
| 15:39 |
Dyrcona |
berick: I've looked at it, but not tried it. |
| 15:39 |
mmorgan |
...also 2.8.2 |
| 15:39 |
Dyrcona |
berick: Also, I'm not able to reproduce the problem in lp /1465847. I get 50 results back, believe it or not. |
| 15:40 |
Dyrcona |
oops. lp 1465847 |
| 15:40 |
pinesol_green |
Launchpad bug 1465847 in Evergreen 2.8 "Empty patron search can lead to heavy DB query / client error" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1465847 |
| 15:40 |
mmorgan |
Bmagic: What don't you like about the unified editor? |
| 15:40 |
Dyrcona |
(too much copy/pasted) |
| 15:40 |
Bmagic |
mmorgan: I think it's great. Our members didnt like it. I really dont know the details |
| 15:43 |
berick |
Dyrcona: k. it may not always produce an error. i guess it depends on the data set / db / whatever |
| 15:43 |
Bmagic |
mmorgan: so you don't have this problem? what version are you using? |
| 15:43 |
Dyrcona |
berick: That's what I'm thinking. I'll go ahead and load the branch to see what happens then. |
| 15:44 |
berick |
Dyrcona++ |
| 15:47 |
mmorgan |
It's 2.8.2. Just to be sure - you're clicking on the edit link next to an item on the opac screen, making an edit to the call number, then clicking on Edit then Re-barcode, making an edit to the item, then clicking Modify Copies? |
| 15:56 |
artunit |
jeff, krvmga: sorry to miss the syrup questions, i forgot to set my status when i went to the east cost last week and have been a little consumed trying to set up an IA book scanner since i returned |
| 16:01 |
artunit |
if i remember right, the IDL is looked up on startup via http:// or file://, we haven't been running it in the last year, reserve readings have sort of been pushed back to the profs, though there's talk about going back to it for the Fall |
| 16:04 |
|
bmills joined #evergreen |
| 16:04 |
Bmagic |
mmorgan: that is correct |
| 16:05 |
Bmagic |
mmorgan: if we start with holdings maintenance and "replace barcode" - same routine, it works |
| 16:09 |
* dbs |
waves at artunit |
| 16:09 |
mmorgan |
Bmagic: Both workflows are working fine on our 2.8.2 training server. |
| 16:09 |
dbs |
I miss you man! |
| 16:10 |
* artunit |
waves back |
| 16:10 |
artunit |
me too! |
| 16:10 |
Bmagic |
mmorgan: omg - I think autogen solved it |
| 16:11 |
mmorgan |
Ah yes, autogen is often the answer when there's odd behavior :) |
| 16:13 |
bshum |
If... I were to void stuff from money.billing and money.payment for a given transaction... |
| 16:13 |
bshum |
That would be zero I think |
| 16:13 |
bshum |
Meaning like nothing was billed against the transaction, and nothing was paid against it. |
| 16:13 |
bshum |
And since money.payment goes towards all the other tables |
| 16:13 |
bshum |
Like forgive_payment / credit_payment, etc. |
| 16:14 |
bshum |
? |
| 16:14 |
bshum |
So that means I shouldn't have to check each table individually to make sure. |
| 16:14 |
bshum |
I think. |
| 16:18 |
mmorgan |
bshum: logically, it makes sense - but how do you void a payment? |
| 16:19 |
mmorgan |
just update the voided field in the payment table to true? |
| 16:20 |
bshum |
mmorgan: that's kind of what I was thinking |
| 16:21 |
* mmorgan |
thought there was more magic around voiding than that :) |
| 16:21 |
bshum |
I mean void to true, voider to some user, and void time to now() |
| 16:21 |
bshum |
But yeah |
| 16:22 |
jeff |
beware: while the underlying schema contains a voided bool on payments, i am not currently aware of any code that sets it, so i suspect that it is entirely untested and you may encounter bugs if you decide to start setting it manually in the db. |
| 16:22 |
bshum |
jeff: That's kind of what I was worried about. |
| 16:23 |
Dyrcona |
jeff: I think the db and most backend code is aware of the payment.void field, there's nothing in the client for it though. |
| 16:23 |
csharp |
request open-ils.circ open-ils.circ.money.billing.void "<authtoken>" <list of bill IDs> via srfsh works too |
| 16:24 |
Dyrcona |
I could be wrong/confusing it with code from conditional negative balances and other branches. |
| 16:26 |
mmorgan |
Stompro: I ran your orphan sockets command on our 4 bricks again, results: 309, 345, 375, 245 (for reference, it was 224, 219, 251, 223 5 hours ago). The numbers have fluctuated, but overall crept up slightly. |
| 16:27 |
mmorgan |
However, on our single server training installation, I'm seeing the number increase by 5 each time I reload a full record page. I'm not seeing the number go down there, currently it's at 4028. I wonder if the problem is more evident on a single server installation. |
| 16:28 |
dbs |
Ours is a single server installation. |
| 16:28 |
dbs |
Still at 0 |
| 16:31 |
Stompro |
mmorgan, Yeahh, I'm glad you can see the issue, even if it isn't a problem for you. |
| 16:34 |
bshum |
Bmagic: mmorgan: Yeah I think autogen was the problem we ran into after we upgraded to a version with those edit links in the catalog for staff client. |
| 16:34 |
* bshum |
vaguely remembers dealing with that once upon a time, anyways |
| 16:45 |
* Dyrcona |
makes it a rule to run autogen.sh after every upgrade. |
| 16:45 |
Dyrcona |
Even when it isn't needed, it doesn't hurt. |
| 16:50 |
Dyrcona |
So, I saw something funny this afternoon with the web staff client and the OPAC. |
| 16:50 |
Dyrcona |
I logged into the web staff client. |
| 16:50 |
Dyrcona |
Then, after looking at some of the cataloging functionality in sprint2, I logged out. |
| 16:51 |
Dyrcona |
I opened the OPAC, and my top bar stuff was missing. |
| 16:51 |
Dyrcona |
The OPAC also behaved as if I were logged in when I went to myopac/home. |
| 16:52 |
Dyrcona |
I wager this has something to do with the two sharing login credentials. |
| 16:52 |
Dyrcona |
I also don't recall seeing this before loading sprint2, so I'll do some more poking tomorrow before opening a launchpad bug. |
| 16:54 |
Dyrcona |
Gonna build a new vm and all that in the morning. |
| 17:24 |
|
mmorgan left #evergreen |
| 20:57 |
|
bshum joined #evergreen |
| 20:57 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 20:58 |
|
bmills joined #evergreen |
| 20:59 |
|
Christineb joined #evergreen |
