Evergreen ILS Website

IRC log for #evergreen, 2015-08-12

| 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: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.o​rg/?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-c​onfigurations-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/evergree​n/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/evergree​n/2015/evergreen.2015-07-01-15.02.log.txt
13:59 jeff oh. 2015-08-05?
13:59 jeff http://evergreen-ils.org/meetings/evergree​n/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

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