| # | Time | Nick | Message |
|---|
| # | 01:19:30 | elene has joined #evergreen |
| # | 03:46:36 | _bott_ has quit IRC |
| # | 03:47:32 | _bott_ has joined #evergreen |
| # | 04:56:05 | _bott_ has quit IRC |
| # | 04:56:05 | Callender has quit IRC |
| # | 04:56:05 | AaronZ-PLS has quit IRC |
| # | 04:56:05 | sylvar has quit IRC |
| # | 04:56:05 | eeevil has quit IRC |
| # | 04:56:05 | shadowspar has quit IRC |
| # | 04:56:06 | mrpeters-isl has quit IRC |
| # | 04:56:06 | asmodai has quit IRC |
| # | 04:56:06 | kbeswick has quit IRC |
| # | 04:56:06 | bwicksall has quit IRC |
| # | 04:59:36 | _bott_ has joined #evergreen |
| # | 04:59:36 | Callender has joined #evergreen |
| # | 04:59:36 | AaronZ-PLS has joined #evergreen |
| # | 04:59:36 | sylvar has joined #evergreen |
| # | 04:59:36 | eeevil has joined #evergreen |
| # | 04:59:36 | shadowspar has joined #evergreen |
| # | 05:00:14 | mrpeters-isl has joined #evergreen |
| # | 05:00:14 | asmodai has joined #evergreen |
| # | 05:00:14 | kbeswick has joined #evergreen |
| # | 05:37:48 | mrpeters-isl has quit IRC |
| # | 05:37:48 | asmodai has quit IRC |
| # | 05:37:48 | kbeswick has quit IRC |
| # | 05:39:20 | mrpeters-isl has joined #evergreen |
| # | 05:39:20 | asmodai has joined #evergreen |
| # | 05:39:20 | kbeswick has joined #evergreen |
| # | 06:33:10 | csharp___ is now known as csharp_GPLS |
| # | 07:10:55 | csharp_GPLS is now known as csharp__ |
| # | 07:49:42 | collum has joined #evergreen |
| # | 08:06:22 | akilsdonk has joined #evergreen |
| # | 08:07:09 | tspindler has joined #evergreen |
| # | 08:12:49 | mrpeters-isl has quit IRC |
| # | 08:19:41 | csharp__ | good morning all, I'm chasing the trail of some "lost" functionality between 1.6.1 and 2.1 regarding the ability to "Retrieve Hold Patron" from the F5 item status screen (and possibly from the checkin screen)... |
| # | 08:19:58 | csharp__ | any clues on what got changed and why? |
| # | 08:21:52 | tspindler | gm, i have a different question, wasn't there a file to run to link authorities to the bibs? I am certain I saw that somewhere but can't find it now |
| # | 08:33:12 | tsbere | csharp__: Not sure what you are going after there. Unless the item is on the hold shelf that patron may be wrong, for the record. |
| # | 08:41:27 | csharp__ | tsbere: use case: http://paste.lisp.org/display/127739 - from the Helpdesk ticket submitted to us |
| # | 08:42:47 | csharp__ | if I knew the controlling file, I could look up the commit history and infer what/why from the comments, probably |
| # | 08:44:32 | kmlussier has joined #evergreen |
| # | 08:44:54 | mrpeters-isl has joined #evergreen |
| # | 08:45:32 | mrpeters-isl | morning, I'm still looking for a home for the new Evergreen Master Development VM. Anyone who can upload it to evergreen-ils.org for me? |
| # | 08:45:47 | mrpeters-isl | (and maybe a tester or 2) |
| # | 08:46:22 | senator | mrpeters-isl++ for making it |
| # | 08:46:46 | senator | i can't upload for it, but will test (eventually; in a low-bandwidth situation here right now) |
| # | 08:47:10 | mrpeters-isl | cool. i probably need moodapoo or bshum. |
| # | 08:47:45 | tsbere | csharp__: Would need to know where the "retrieve the hold patron" button was. >_> |
| # | 08:48:04 | tsbere can upload to evergreen-ils.org |
| # | 08:48:24 | tsbere | Forgot I could, was given that power when I was building stuff previously. |
| # | 08:48:26 | tsbere | >_> |
| # | 08:48:31 | mrpeters-isl | tsbere: i'll upload it to someoen where you can grab it from then |
| # | 08:48:36 | mrpeters-isl | *somewhere |
| # | 08:48:49 | tsbere | Oh, even better, I won't even have to download it then! ;) |
| # | 08:48:57 | mrpeters-isl | right! |
| # | 08:49:07 | tsbere | Just tell the server to grab it |
| # | 08:53:06 | Dyrcona has joined #evergreen |
| # | 08:55:28 | mrpeters-isl | Dev VM (Master as of 2/10): http://apple.evergreen.lib.in.us/downloads/EvergreenMasterSqueeze.ova |
| # | 08:56:28 | collum has quit IRC |
| # | 08:56:37 | bwicksall has joined #evergreen |
| # | 08:59:01 | mrpeters-isl | tsbere: just let me know where it ends up so I can update the dev:summer_of_coding_ideas page. |
| # | 08:59:04 | csharp__ | tsbere: I'm trying to resurrect our legacy cluster to be sure, but if memory serves, it was in the Actions for this Record menu/context menu |
| # | 08:59:35 | collum has joined #evergreen |
| # | 09:01:00 | bwicksall has quit IRC |
| # | 09:03:02 | tsbere has a corrupt entry in his SSH config.....and it happens to be the one that contains the port for SSH on evergreen-ils.org >_> |
| # | 09:04:20 | mrpeters-isl | Do these upgrade instructions for the VM look appropriate to everyone? http://pastie.org/3373792 |
| # | 09:05:21 | Meliss has joined #evergreen |
| # | 09:06:05 | tsbere | there we go, found a backup |
| # | 09:07:01 | tsbere | mrpeters-isl: Why not just automate all of that in a bash script? :P |
| # | 09:07:46 | mrpeters-isl | i always like to go through it one by one in case something goes wrong |
| # | 09:12:37 | mrpeters-isl | though, if you have something like that share it up :) |
| # | 09:16:03 | tsbere | mrpeters-isl: http://pastie.org/3373863 |
| # | 09:16:37 | mrpeters-isl | sweeeeet! |
| # | 09:18:49 | mrpeters-isl | how does the <Filename> differ from <stamp>? |
| # | 09:19:02 | tsbere | mrpeters-isl: Well, the script has to have a filename, doesn't it? Otherwise how will you run it? |
| # | 09:19:18 | mrpeters-isl | oh, lol i was reading it like a variable. i'm sorry |
| # | 09:20:08 | tsbere | I am sure you can see some patterns for "how to make this do more but fail when something goes wrong" ;) |
| # | 09:21:21 | jenny1 has joined #evergreen |
| # | 09:21:35 | tsbere | mrpeters-isl: That a vmware file you handed me? |
| # | 09:21:59 | mrpeters-isl | its an OVA, i used virtualbox but i think you can import it to vmware |
| # | 09:22:22 | tsbere is trying to decide where to put it |
| # | 09:23:30 | mrpeters-isl | old one was in ~denials |
| # | 09:23:39 | tsbere | yea, would rather not have them in user folders ;) |
| # | 09:24:15 | mrpeters-isl | http://evergreen-ils.org/downloads.php could probably use an update after a couple people test |
| # | 09:26:00 | tsbere | mrpeters-isl: Decided on http://evergreen-ils.org/downloads/vm/EvergreenMasterSqueeze.ova |
| # | 09:26:44 | mrpeters-isl | cool |
| # | 09:28:51 | alynn26 has joined #evergreen |
| # | 09:30:43 | alynn26 has quit IRC |
| # | 09:32:22 | tsbere | csharp__: I think your staff are seeing things. Or not seeing things. Hard to say, really. Can't find significant *removals* from those menus at all. |
| # | 09:33:41 | mtcarlson has joined #evergreen |
| # | 09:33:51 | jeff | it's in the (old/legacy?) copy_details.xul. |
| # | 09:33:55 | jeff | Open-ILS/xul/staff_client/server/circ/copy_details.xul |
| # | 09:34:03 | jeff | 223: <button id="r_hold" label="&staff.circ.copy_details.r_hold.label;" accesskey="&staff.circ.copy_details.r_hold.accesskey;" oncommand="retrieve_hold_patron();"/> |
| # | 09:34:37 | tsbere | jeff: Well, that isn't in the menus, which is where I was told to look :P |
| # | 09:34:43 | mrpeters-isl | dbwells: i'm noticing my changes to remove the facet header images still haven't made it in. Am I still doing something wrong with my commits? |
| # | 09:34:49 | bwicksall has joined #evergreen |
| # | 09:35:20 | tsbere | mrpeters-isl: I can point you at a number of pullrequest bugs that have been sitting around for months. >_> |
| # | 09:35:34 | mrpeters-isl | well, this is something dbwells and i were working on last week |
| # | 09:35:51 | dbwells | mrpeters-isl: that should be in there, one second |
| # | 09:35:53 | mrpeters-isl | i thought it got pulled into master, but maybe i was wrong |
| # | 09:36:33 | dbwells | mrpeters-isl: isn't it this? http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c01869eb3999223b41e792e913f8f43e1213178a |
| # | 09:36:34 | mrpeters-isl | i might know the problem...i think i installed from senator's search hint branch |
| # | 09:36:45 | mrpeters-isl | yes...im sorry |
| # | 09:37:03 | dbwells | mrpeters-isl: that might do it :) no problem |
| # | 09:37:05 | mrpeters-isl | tsbere's script worked good, i just wasn't on "master" |
| # | 09:38:14 | mrpeters-isl | has the search hint stuff been pulled into master yet? |
| # | 09:38:44 | csharp__ | jeff: thanks for that tip |
| # | 09:38:52 | csharp__ | tsbere: thanks for looking too ;-) |
| # | 09:39:38 | tsbere | mrpeters-isl: You may want to add some more stuff to the script. For example, building clients might be a nice touch. |
| # | 09:39:53 | mrpeters-isl | yep, agreed. ill see what i can figure otu. |
| # | 09:40:43 | tsbere | mrpeters-isl: Change to the staff_client directory, "make updates-client". Then probably rm -rf /openils/var/updates/archives/* because automatic updates won't actually be enabled. |
| # | 09:40:52 | tsbere | make sure nsis, zip, unzip are installed though ;) |
| # | 09:41:09 | mrpeters-isl | right |
| # | 09:41:32 | mrpeters-isl | cd /home/opensrf/Evergreen/Open-ILS/xul/staff_client && make STAFF_CLIENT_VERSION=master02132012 rigbeta devbuild AUTOUPDATE_HOST=master.evergreen.lib.in.us updates-client rebuild |
| # | 09:41:36 | mrpeters-isl | was what i usually do |
| # | 09:42:08 | tsbere | I would avoid the "cd blah && do something" model in favor of "cd blah <newline> do something" model in a script ;) |
| # | 09:42:34 | mrpeters-isl | sure, agreed |
| # | 09:42:43 | tsbere | mrpeters-isl: Also, the rebuild seems incorrectly placed there..... |
| # | 09:43:04 | mrpeters-isl | oh, maybe thats why my partial updates never work? |
| # | 09:43:09 | tsbere | you want rebuild *before* things like devbuild, but *after* things like rigbeta |
| # | 09:43:25 | mrpeters-isl | aha ok |
| # | 09:44:00 | tsbere | rebuild and devbuild both rely on "build". If devbuild runs first then rebuild won't re-run build, which is needed for how it functions. |
| # | 09:44:14 | mrpeters-isl | great info. thanks |
| # | 09:44:20 | tsbere | Of course, rebuild also throws out some of the options like the version, in favor of the previously built version |
| # | 09:44:57 | csharp__ | huh - function retrieve_hold_patron() is still there in copy_details.xul... |
| # | 09:46:51 | j_scott has joined #evergreen |
| # | 09:47:51 | bshum waves at j_scott |
| # | 09:48:40 | mtcarlson_ has joined #evergreen |
| # | 09:49:23 | j_scott waves to everyone |
| # | 09:50:28 | pinesol_green has joined #evergreen |
| # | 09:53:47 | csharp__ | okay - a general question... have sites that have upgraded from 1.6 to 2.0/2.1 seen a rise in problems related to client bandwidth (screen freezes, network failures, etc.)? |
| # | 09:54:07 | csharp__ | we have libraries who were (purportedly) fine on 1.6 really struggling with 2.1 |
| # | 09:54:14 | mrpeters-isl | csharp__: i dont think we have. just the issue we're having where Cat service will die off randomly |
| # | 09:54:33 | Dyrcona | csharp__: we have both from some libraries. :) |
| # | 09:54:43 | csharp__ | huh |
| # | 09:54:50 | Dyrcona | mrpeters-isl: It isn't random. We've traced it to large deletes. |
| # | 09:54:59 | mtcarlson_ has quit IRC |
| # | 09:55:23 | tsbere | mrpeters-isl: Specifically item status "load this CSV file then try and delete them all" and "take this really full bucket and delete them all" |
| # | 09:55:32 | Dyrcona | csharp__: We've always been on 2.1+ and our some of our members complain of chronic Evergreen slowness and "network errors." |
| # | 09:55:33 | mrpeters-isl | hmm i havent heard back from gmcharlt and berick about our side of it yet |
| # | 09:55:55 | mrpeters-isl | i dont think anyone uses csv to feed deletes here. maybe full buckets, but i dont know. |
| # | 09:56:21 | tsbere | mrpeters-isl: I think the csv to feed deletes was because we told them to stop doing the mass bucket deletes. So they worked around that....... |
| # | 09:56:29 | Dyrcona | where "full" means somewhere upwards of 100 copies. We don't have a solid threshold. |
| # | 09:56:30 | mrpeters-isl | crafty catalogers ;) |
| # | 09:57:03 | mrpeters-isl | well im glad to hear some progress is being made on that issue then |
| # | 09:57:27 | Dyrcona | mrpeters-isl: You'll have to share some of your support $$ with us. :) |
| # | 09:58:30 | Dyrcona | lp921812 |
| # | 09:58:41 | Dyrcona | Launchpad bug 921812 |
| # | 09:58:41 | pinesol_green | Launchpad bug 921812 in Evergreen "Network Error when deleting all copies in bucket" (affected: 1, heat: 6) [Undecided,In progress] https://launchpad.net/bugs/921812 - Assigned to Jason Stephenson (jstephenson) |
| # | 09:59:58 | csharp__ is now known as csharp |
| # | 10:01:34 | csharp | Dyrcona: thanks for the information - that is exactly what we're hearing from *some* but not all of our libraries |
| # | 10:02:10 | bshum | csharp: fwiw, we also get periodic network difficulties from our libs, but I don't feel it's more or less than when we were on 1.6 vs. 2.0 |
| # | 10:02:30 | bshum | Usually tends to be a network issue. Or our statewide network going down.... but... yeah. |
| # | 10:04:32 | berick | Dyrcona: 921812 is the cause of the systemic open-ils.cat failures? Or is it just a failure within that particular action? |
| # | 10:05:19 | Dyrcona | berick: We always check the logs when the open-ils.cat failures occur, and so far there has been a large delete going on every thime. |
| # | 10:05:40 | Dyrcona | berick: Since we've told our staff not to batch delete, the crashes have not happened. |
| # | 10:05:56 | csharp | bshum: good to know |
| # | 10:06:05 | Dyrcona is working on a more efficient batch delete that the client can use. |
| # | 10:06:23 | berick tries to finally recreate the problem |
| # | 10:06:24 | csharp | we are now seeking to establish a threshold for a "recommended" bandwidth requirement |
| # | 10:06:33 | mrpeters-isl | Dyrcona++ |
| # | 10:07:14 | Dyrcona | csharp: We have comcast business cable at almost all of our sites. Some complain, and others don't. |
| # | 10:07:19 | mrpeters-isl | csharp: we have a very helpful ISP who most of our libraries use. they were nice enough to configure traffic shaping so that all traffic to our Evergreen network had priority over other traffic on those lines. |
| # | 10:07:30 | Dyrcona blames shoddy infrastructure in some localities vs. others. |
| # | 10:09:57 | csharp | most of our libraries are on the aging state-managed network that connects the state colleges and universities |
| # | 10:12:21 | mrpeters-isl | csharp: maybe they can do something similar then? |
| # | 10:13:15 | mrpeters-isl | it helped our libraries who had just a single T1 with a big group of users who'd sit on YouTube, etc. |
| # | 10:13:25 | Dyrcona | We used to have packet shapers when we had a private WAN. Now everything comes over the Internet to us, so shapers are next to useless. |
| # | 10:14:02 | Dyrcona | Anyone have an example of using a request callback in the staff client? Looking at Vandelay was useless since it uses tpac. |
| # | 10:16:43 | berick | Dyrcona: to be clear, "delete all copies from a bucket", do you mean the "Remove Selected From Bucket" action or the "Delete All From Catalog" action? |
| # | 10:16:53 | tsbere | berick: The latter |
| # | 10:16:58 | berick | thanks |
| # | 10:16:58 | Dyrcona | berick: Delete all from catalog |
| # | 10:17:14 | tsbere | berick: Similar issue with item status and large lists in there, too. |
| # | 10:17:28 | Dyrcona | I think the issue is that if fleshes all the copies and sends all of that fleshed data back to the server. |
| # | 10:18:14 | tsbere is fairly confident that is the issue, the cat listener on the backend falls over and dies while trying to process the giant request <_< |
| # | 10:18:47 | Dyrcona | copy_bucket_batch_copy_delete in copy_buckets.js for the client side of things. |
| # | 10:19:22 | berick | interesting. you'd think ejabberd would cut the apache client off if the request was too big |
| # | 10:19:29 | Dyrcona was working on make a smaller request for the delete. |
| # | 10:19:51 | tsbere | berick: The problem is that we set *really* large message sizes. |
| # | 10:19:55 | Dyrcona | berick: We think it might be having issues even if the message is under the max_stanza_size. |
| # | 10:20:14 | berick | i see.. |
| # | 10:20:24 | berick | how big is your max_stanza_size? |
| # | 10:20:27 | Dyrcona | Yeah, delete these 2,600 fleshed copies for me, please...... |
| # | 10:20:35 | Dyrcona | we've tried infinity.... |
| # | 10:20:38 | tsbere | berick: Near as I can tell, large message sizes for *drone responses* are a good thing, and prevent issues with a lot of calls. Large message sizes for *listener requests* are a bad thing..... |
| # | 10:20:45 | wlayton has joined #evergreen |
| # | 10:22:09 | senator | Dyrcona: http://pastesite.com/31595 |
| # | 10:22:52 | Dyrcona | senator++ |
| # | 10:24:03 | berick | maybe i'm crazy, but wouldn't it be better to let excessively large requests like that fail than to have them gumming up the works for everyone? from a sysadmin perspective, that is. from a code perspective, yeah, let's fix it.. |
| # | 10:24:30 | Dyrcona | berick: trouble is, the large request gum everything up when the fail. |
| # | 10:24:51 | Dyrcona | berick: I also think, it's 2012, if they want to delete 2,600 copies, then they should be able to do it. |
| # | 10:25:07 | berick | i'm not saying they shouldn't |
| # | 10:25:20 | berick | i'm saying, when it fails, we fix it |
| # | 10:25:23 | tsbere | berick: I would rather they fail then crash out the system, and I would rather they work than fail. The only way I can think of to fail them early is to put a limit at the translator/gateway for max size....or at the router level for "reject any message bigger than X passing through you" |
| # | 10:25:54 | Dyrcona | anyway, senator's paste point me in a good direction. I'm going to start a new branch and see if I can fix both batch deletes in one go. |
| # | 10:26:42 | Dyrcona | The deletes don't actually cause a problem when done properly on the back end. I've written a couple of scripts as workarounds for now. |
| # | 10:27:04 | Dyrcona | Staff send me the bucket id or a csv of barcodes. |
| # | 10:28:13 | berick | tsbere: hmm, if max_stanza_size catches it, it won't even get to the router. it should die on the way from the apache client to the ejabberd server (en route to the router). the only thing that should happen is the apache process is kicked off of jabber (and the request fails, of course). |
| # | 10:28:20 | berick | i'm curious what kind of problems that causes |
| # | 10:28:56 | tsbere | berick: Low max stanza size means some *responses* don't work. Large max stanza size means big requests kill things. We need an incoming max compared to an outgoing max, and ejabberd only has one. |
| # | 10:30:01 | Dyrcona | sounds like a problem at the OpenSRF layer. Perhaps listeners need to be threaded? |
| # | 10:30:08 | berick | or we fix the code to stream responses |
| # | 10:30:38 | Dyrcona | how about streaming requests? 'cause we see the problem before the request is processed. |
| # | 10:30:59 | tsbere | yea. The problem is the message from the router to the perl listener being far too large. :/ |
| # | 10:32:56 | berick | sure, for those the API calls need to change. there's no sense in clients having to send MB's of data for an API call to, for example, delete copies. (IOW, what Dyrcona is doing in the ticket) |
| # | 10:34:27 | berick jacks up his max_stanza_size and sees what kind of damage he can do |
| # | 10:35:33 | tsbere | berick: The keyword infinite is valid for max_stanza_size (not quoted) and is ejabberd's default. Just so you know. |
| # | 10:35:58 | berick | thanks, was wondering about that |
| # | 10:37:07 | eeevil | Dyrcona: there was support for streaming requests, actually, in the perl implementation. but that got killed with opensrf 2.0 |
| # | 10:37:16 | mrpeters-isl | tsbere: When you have some time -- what would cause "Update XML file malformed (200)" when i try to use auto updates? |
| # | 10:38:01 | tsbere | mrpeters-isl: *lots* of things. Bad version data and/or bad stamp data might be a good start. |
| # | 10:42:29 | mrpeters-isl | thanks |
| # | 10:57:49 | tsbere | berick / Dyrcona / whoever else: Just thought of why the listener may be falling apart.....could the max rate settings in ejabberd be slowing things down to the point of timeouts? Perhaps setting those to the same as the max stanza size (when not using infinity) might help. |
| # | 11:03:38 | berick | aha, was able to kill it. |
| # | 11:03:47 | berick | confirmed the listener is not reading the entire message |
| # | 11:04:05 | berick | I wonder if the open-ils.cat network buffer just filled up and started dropping packets |
| # | 11:04:30 | tsbere | could be |
| # | 11:06:43 | berick | for me, the listener didn't die. it read what it could and passed it off to the child process. the child proc. died and logged an error about premature end of data in the xml |
| # | 11:06:46 | berick | the listener is fine though |
| # | 11:07:06 | berick | after a brief period of not responding, while it read the data |
| # | 11:07:11 | tsbere | berick: Well, sometimes. |
| # | 11:07:23 | berick | k |
| # | 11:07:25 | tsbere | berick: Do what you just did 9 times in rapid succession, see what the router does about it. |
| # | 11:07:58 | tsbere finds the "request router opensrf.router.info.class.list" srfsh command useful in that case, for the record |
| # | 11:09:09 | tsbere | or at least I think that was it <_< |
| # | 11:09:30 | elene has quit IRC |
| # | 11:09:33 | tsbere | yea, that is the one |
| # | 11:17:15 | tsbere | reporting template creator-- |
| # | 11:17:22 | tsbere | In fact.... |
| # | 11:17:23 | tsbere | reporting template creator-- |
| # | 11:17:24 | tsbere | reporting template creator-- |
| # | 11:17:25 | tsbere | reporting template creator-- |
| # | 11:17:26 | tsbere | <_< |
| # | 11:20:07 | bshum | Heh |
| # | 11:21:50 | tsbere may have to add "re-write that POS" to this list of things to work on |
| # | 11:25:05 | eeevil | tsbere: I'll send the librarians with 50k templates that they need to rewrite to /your/ house |
| # | 11:25:47 | tsbere | eeevil: And if the new one is 100% data compatible with the existing one? |
| # | 11:25:58 | eeevil | good luck with all that |
| # | 11:26:00 | tsbere | At least for the existing one's templates |
| # | 11:26:16 | eeevil | srsly, good luck |
| # | 11:38:16 | mrpeters-isl | any idea of a "safe" number of items in a bucket for now to prevent this? |
| # | 11:39:55 | berick | mrpeters-isl: i'm sure it varies, but on my last run, mine died around the 800th copy. |
| # | 11:40:14 | mrpeters-isl | i was thinking we'd say no more than 20 or 30 in a bucket until this is fixed |
| # | 11:40:46 | mrpeters-isl | think it's only deleting from buckets, or maybe other actions with buckets too? |
| # | 11:42:36 | berick | mrpeters-isl: i imagine any kind of mass update/delete on copies from the staff client would have the same effect |
| # | 11:42:45 | plux has joined #evergreen |
| # | 11:44:09 | bshum | csharp: I added the revised link info to git and will figure out how to deal with the local change you made to the file on Lupin |
| # | 11:47:30 | bshum | All settled, I think. |
| # | 11:47:35 | bshum | csharp++ |
| # | 11:47:57 | stompro__ has quit IRC |
| # | 11:48:16 | Stompro has joined #evergreen |
| # | 11:48:22 | csharp | bshum: ah |
| # | 11:48:33 | csharp | wasn't thinking about git :-) |
| # | 11:49:46 | tsbere | eeevil: For the record, my goal with re-writing the front end of the reporter interface would be "don't even touch clark kent" - That should make it a lot easier to stay backwards comptaible ;) |
| # | 11:50:00 | tsbere | er, compatible. |
| # | 11:50:06 | tsbere is having spelling issues today, apparently |
| # | 11:50:20 | elene has joined #evergreen |
| # | 11:53:11 | denials_ | tsbere: I'm sure eeevil can take it, but I'm not comfortable with community members publicly calling someone else's work a "POS". For whatever my opinion is worth. |
| # | 11:55:05 | mrpeters-isl | tsbere: its lightyears better than the first reports interface! |
| # | 11:55:30 | mrpeters-isl | we still have a few reports written in that one...its much less flexible |
| # | 11:56:48 | mrpeters-isl | anyone from the dig team kicking around? I was wondering why http://docs.evergreen-ils.org/1.6/draft/html/UsingtheBookingModule.html isn't included in the 2.x versions of the documentation? |
| # | 11:57:00 | eeevil | tsbere: the version there is the 4th UI that's existed ... there's plenty of room for improvement, but IMO the lesson is "building a template is hard, and the UI can only help so much if the user isn't familiar with the required concepts" ... if, of course, the goal is a general system. |
| # | 11:57:43 | mrpeters-isl | the 1.6 version did the trick for us, fwiw, so i think it would be 2.x doc worthy |
| # | 11:58:18 | tsbere | denials_: I am several templates into my day today....and only have one to show, due to a number of issues. I am making a list of things to look at fixing and/or adding. But most of my list is what I consider to be bugs today. |
| # | 11:59:03 | kmlussier | mrpeters-isl: Probably because nobody has reviewed it and confirmed that there are no changes for 2.x. |
| # | 11:59:14 | mrpeters-isl | aha good reason :) |
| # | 11:59:27 | denials_ | tsbere: I understand that you're probably neck-deep in annoyances, but I wouldn't be interested in joining a community that slings mud at one another. And if we're trying to grow our community, we need to support one another. |
| # | 11:59:42 | mrpeters-isl | as far as we've found, that documentation was helpful |
| # | 12:00:14 | kmlussier | mrpeters-isl: If it looks good to you and you send a message to the DIG list, rsoulliere will probably just move what's there to the 2.x docs. |
| # | 12:00:39 | mrpeters-isl | 10-4 |
| # | 12:00:43 | tsbere | eeevil: Running into a pile of things that should work but don't doesn't help those of us who are familiar with those concepts. |
| # | 12:00:58 | mrpeters-isl | tsbere: i can proabbly help with building some templates |
| # | 12:01:05 | mrpeters-isl | i think im pretty good at it |
| # | 12:01:45 | berick | denials_++ |
| # | 12:02:14 | mrpeters-isl | if anyone has a second to confirm my subscription to the dig list i'd <3 you |
| # | 12:02:41 | tsbere | mrpeters-isl: My issues stem from things like "oh, hey, a date picker....for a value that shouldn't be a date" |
| # | 12:05:14 | mrpeters-isl | ok |
| # | 12:05:50 | mrpeters-isl | thats interesting, haven't seen a case like that. will be glad to see it fixed though if it is happening. |
| # | 12:13:02 | luisb has joined #evergreen |
| # | 12:20:19 | jenny2 has joined #evergreen |
| # | 12:23:10 | jenny1 has quit IRC |
| # | 12:23:11 | jamesrf has quit IRC |
| # | 12:23:15 | jamesrf_ has joined #evergreen |
| # | 12:35:09 | elene has quit IRC |
| # | 12:54:21 | Dyrcona | Whee! My client has drifted off to La-La Land. |
| # | 12:58:45 | Dyrcona | Wow! Twelve kinds of crazy..... |
| # | 12:58:51 | Dyrcona | Don't try this at home, kids! |
| # | 12:59:19 | Dyrcona | Retrieve a bucket with 14,888 copies in it. Try to quit the client while it is loading..... |
| # | 12:59:48 | Dyrcona | Oh, then delete 14,000 of the copy_bucket_item entries behind the client's back.... |
| # | 12:59:49 | bshum | Yikes. |
| # | 13:01:10 | tsbere doesn't think the client can be blamed for going off into la-la land |
| # | 13:02:23 | jamesrf_ is now known as jamesrf |
| # | 13:18:30 | bshum | Sigh, it occurs to me that we never actually decided anything about when to hold the next dev meeting. |
| # | 13:18:42 | bshum | Day/time, etc. |
| # | 13:31:32 | berick | bshum: iir, the plan was to set up a survey. do you know if there is a particular survey app/site people like to use? |
| # | 13:32:38 | tsbere dislikes survey apps and sites in general, but is probably in the minority there |
| # | 13:32:46 | bshum | berick: Oh that's right. I think doodle is usually pretty good. |
| # | 13:32:58 | bshum | I'll go poke around I guess, thanks for the reminder. |
| # | 13:33:06 | berick | bshum++ |
| # | 13:43:54 | Dyrcona doesn't trust his development machine. |
| # | 13:44:14 | Dyrcona | Of course, someone is playing with acq on there at the moment..... |
| # | 13:44:25 | kmlussier | :-) |
| # | 13:44:36 | kmlussier | Dyrcona: Do you want me to get off? |
| # | 13:44:50 | Dyrcona | no, that's all right. |
| # | 13:45:03 | elene has joined #evergreen |
| # | 14:04:06 | elene has quit IRC |
| # | 14:04:45 | Dyrcona | Monster bucket has 13,999 items left. Here we go! |
| # | 14:16:48 | csharp | I need a hold policy that will universally set anything that is reference = true to be non-holdable - can anyone point me in the right direction? |
| # | 14:17:22 | csharp | seems like most of these are "allow the hold" type rules and I don't know how to exclude reference items :-/ |
| # | 14:24:49 | tsbere | csharp: indb? |
| # | 14:25:19 | tsbere | csharp: if so, update everything in the hold table to "reference = false" except for one rule that says "reference=true and holdable = false" |
| # | 14:26:10 | bshum | csharp: What I would try in that situation, if you only wanted say... one rule to rule them all might be to write a single rule that says all reference = true is not holdable. |
| # | 14:26:15 | bshum | Then adjust the hold weight |
| # | 14:26:21 | bshum | So that it matches on that the most. |
| # | 14:26:33 | bshum | And then assign all your other hold rules with reference = false |
| # | 14:26:38 | bshum | So that it knows the difference. |
| # | 14:27:15 | tsbere | bshum: If you alter every rule to include the reference flag then weight adjusting isn't needed. The ones that don't match the reference flag get thrown out anyway. ;) |
| # | 14:27:25 | bshum | tsbere: Oh true. |
| # | 14:27:30 | bshum | Yes, then do that csharp :P |
| # | 14:29:29 | natschil has joined #evergreen |
| # | 14:30:42 | kmlussier_ has joined #evergreen |
| # | 14:30:48 | Dyrcona | great.... |
| # | 14:30:58 | Dyrcona | flesh a copy bucket with 13,999 entries. |
| # | 14:31:13 | Dyrcona | gather up the target_copy ids from the bucket items. |
| # | 14:31:14 | vxbush has joined #evergreen |
| # | 14:31:40 | Dyrcona | make a call to my experimental open-ils.cat.asset.copy.batch.delete.override and get no output and no copies deleted. |
| # | 14:31:56 | Dyrcona | no events thrown or returned anywhere, either. :( |
| # | 14:32:30 | kmlussier has quit IRC |
| # | 14:32:58 | Dyrcona | works fine with 53 and 84 item count buckets. |
| # | 14:38:38 | csharp | tsbere: bshum: thanks - will try |
| # | 14:41:45 | csharp | arg - you can't edit hold policies! |
| # | 14:41:51 | tsbere | ? |
| # | 14:41:58 | tsbere | double-click on them? |
| # | 14:43:15 | csharp | okay - that works - I've gotten unique constraint errors (and just did when trying to batch change them) |
| # | 14:43:21 | bshum | *cough* just use SQL :P |
| # | 14:43:42 | bshum | Oh, weird. |
| # | 14:44:01 | tsbere | csharp: You probably already had some with the flag set |
| # | 14:47:10 | csharp | http://paste.lisp.org/display/127754 |
| # | 14:48:25 | tsbere | csharp: Yea, you probably already have a rule that differs from a second rule *only* in the value of the reference flag (null compared to true/false) |
| # | 14:53:09 | bshum | tsbere: Do you guys use hold soft stalling? |
| # | 14:53:47 | tsbere | bshum: Not currently, unless someone tweaked settings when I wasn't looking. |
| # | 14:53:51 | bshum | tsbere: Trying to figure out if hold stalling period applies differently with suspended holds, or if it'll ignore the suspended state and go based on the request date only. |
| # | 14:54:08 | bshum | So wait 3 days or whatnot, but that still counts even if the hold is suspended |
| # | 14:54:23 | bshum | So far as I can tell, it doesn't seem to distinguish |
| # | 14:54:25 | bshum | That might be "bad" |
| # | 14:54:27 | tsbere | bshum: If I know the code, the suspended time is included in the stalling period. |
| # | 14:54:44 | tsbere | It has to be, really. There is no record kept of when the hold was "thawed" |
| # | 14:54:49 | bshum | Right. |
| # | 14:54:55 | bshum | No activation date per say |
| # | 14:55:01 | bshum | Peachy. |
| # | 14:55:25 | tsbere | bshum: The activation date may not apply (not provided, manually thawed before it, etc) |
| # | 14:56:05 | tsbere | Would be relatively trivial to add in a new date on holds to say "this hold was active on...." |
| # | 14:57:17 | vxbush | May I post a new question about my upgrading data from 1.6 to 2.1.1? I'm making progress, but I've his a snag running to 2.0 -> 2.1 upgrade script, and not the one I ran into last week (I fixed that.) |
| # | 14:58:07 | wlayton has quit IRC |
| # | 14:58:18 | vxbush | The following code generates an error: In the script 2.0-2.1-upgrade-db.sql, on line 1474, the code is: |
| # | 14:58:35 | vxbush | 1472 CREATE TABLE metabib.record_attr ( |
| # | 14:58:35 | vxbush | 1473 id BIGINT PRIMARY KEY REFERENCES biblio.record_entry (id) ON DELETE CASCADE, |
| # | 14:58:35 | vxbush | 1474 attrs HSTORE NOT NULL DEFAULT ''::HSTORE |
| # | 14:58:35 | vxbush | 1475 ); |
| # | 14:58:53 | vxbush | The error is: 2.0-2.1-upgrade-db.sql:1475: ERROR: type "hstore" does not exist |
| # | 14:59:13 | vxbush | Well, yeah, that makes sense. The question is: Is there something it should be? Is this a typo problem? |
| # | 14:59:25 | gmcharlt | vxbush: you need to make sure that the hstore contrib (if you're running Pg 9.0) or extension (if 9.1.x) is installed |
| # | 15:00:06 | vxbush | Hmm, I'm guessing that's not part of the 9.0_server package. I'll have to research that. Thanks, gmcharlt. I didn't see this come up as a pre-requisite anywhere. |
| # | 15:00:49 | Dyrcona upped the recv timeout to 300 in his client/test script and is now happily deleting 13,999 copies via a copy bucket. |
| # | 15:02:35 | vxbush | Hmmm. postgres-contrib is installed already……. |
| # | 15:02:36 | bshum | fwiw, it definitely mentions the hstore contrib in the upgrading wiki page from 2.0 to 2.1. |
| # | 15:03:38 | gmcharlt | vxbush: right, but the existence of the contrib package doesn't mean that it automatically installs any specific contribs into the database |
| # | 15:03:40 | vxbush | (Thanks, bshum. My problem is having to use CentOS and running into all sorts of weirdness.) |
| # | 15:05:26 | gmcharlt | vxbush: so, psql evergreen -f /path/to/pgcontribs/contrib/hstore.sql |
| # | 15:09:02 | vxbush | gmcharlt: Cool. I never ran into this problem before, so this was a new one on me. Sigh. I'll need to adapt the startup script for postgres to make sure it loads this module, then. |
| # | 15:09:31 | gmcharlt | vxbush: ah, no, it's a once-and-done per database |
| # | 15:10:47 | kmlussier__ has joined #evergreen |
| # | 15:11:29 | vxbush | gmcharlt: ah. Going to play now..... |
| # | 15:11:38 | gmcharlt | enjoy! |
| # | 15:13:04 | kmlussier_ has quit IRC |
| # | 15:13:58 | vxbush | Stupid question: I'm playing with test data now, so I'm blowing away and recreating databases left, right, and center as I perfect my scripts to do this update on the production server. I am assuming said items in the hstore contrib file will need to be applied again if I blow away the evergreen database. |
| # | 15:15:13 | gmcharlt | vxbush: correct |
| # | 15:17:23 | vxbush | gmcharlt: shiny. Okay, off to play some mroe |
| # | 15:20:41 | vxbush | Hmmm. Okay, loaded the contrib file per gmcharlt's psql command, loaded the data fresh, ran 2.0-2.1-upgrade-db.sql, and I'm getting the same error. |
| # | 15:21:11 | vxbush | Perhaps there is another contrib I must add. Let me check bshum's upgrade page again. |
| # | 15:22:32 | vxbush | Nope, but it looks like gmcharlt's psql command wasn't quite complete. Needed to specify the database. |
| # | 15:22:35 | vxbush | Trying again.... |
| # | 15:25:51 | tsbere | eeevil: Now bshum is poking me about if I have heard about holds go home type stuff. You ever get the code that covers that use case out into a visible location? |
| # | 15:26:34 | kmlussier__ | tsbere: Huh, I just got off a conference call where we were discussing that. |
| # | 15:27:42 | eeevil | tsbere: serendipitous timing ... working on making that happen right now |
| # | 15:28:39 | tsbere | Oh good. I can hopefully take that into account for my circ and holds major rewrite project then. :D |
| # | 15:28:54 | eeevil | bshum: I'll alert you, sir, as well |
| # | 15:29:02 | bshum | eeevil: Thank you :P |
| # | 15:29:40 | eeevil | tsbere: trying to remember if you sent plans for that |
| # | 15:29:59 | vxbush | gmcharlt, bshum: much, much better running 2.0-2.1-upgrade-db.sql this time. Besides getting notices that seem informational, I did get one error that might be of concern: |
| # | 15:30:04 | tsbere | eeevil: Still *working* on the plans. >_> Lots of interconnected pieces. Figure I will hit them all at once. |
| # | 15:30:22 | vxbush | At line 8858, the error is: insert or update on table "org_unit_setting_type" violates foreign key constraint "org_unit_setting_type_grp_fkey" |
| # | 15:30:22 | vxbush | DETAIL: Key (grp)=(circ) is not present in table "settings_group". |
| # | 15:30:37 | vxbush | at comment 0633. |
| # | 15:30:48 | bshum | vxbush: Interesting, I think I saw that in my upgrade testing as well (I'm also testing 2.0-2.1) |
| # | 15:31:10 | vxbush | bshum: I'm moving up from 1.6.0.4, so I'm slowly having to build up my process. Should I worry about this? |
| # | 15:31:13 | bshum | But I'm working on other issues along the way. |
| # | 15:31:57 | tsbere | eeevil: I should probably make a page somewhere to keep track of everything I want to hit with the circ/holds reworking. Most of it is in various note files right now. |
| # | 15:32:11 | vxbush | Everything elder was just a notice-level error. |
| # | 15:32:29 | vxbush | elder? ggggr. Everything else was just notices. |
| # | 15:32:44 | eeevil | tsbere: that would be rad |
| # | 15:43:34 | enhancin has quit IRC |
| # | 15:43:59 | enhancin has joined #evergreen |
| # | 15:45:43 | enhancin | I need some generic advice. I've got the 150,000 books in and I put them in in 30 separate chunks...now I'm doing the Holdings and since they're much faster I was wondering if it would be safe to do them all at once, or should I take the same method as before? If i DO do each one separately do I need to run the .sql script in src/support-scripts after each holdings insert or just after all of them? |
| # | 15:50:12 | jenny2 has quit IRC |
| # | 15:52:32 | denials_ wonders whether the 2.0-2.1-upgrade-db.sql that vxbush and bshum are running include the fixes he posted like https://bugs.launchpad.net/evergreen/+bug/893345 |
| # | 15:52:32 | pinesol_green | Launchpad bug 893345 in Evergreen "Upgrade from 2.0 to 2.1 fails due to conflicts with custom permission groups" (affected: 1, heat: 6) [High,Fix committed] |
| # | 15:52:49 | bshum | denials_: Maybe not, but I'm toying with the one in master. |
| # | 15:53:13 | plux has quit IRC |
| # | 15:55:00 | bshum | denials_: I'll let you know though. After I'm done crying my way through a list of requested "enhancements" |
| # | 15:55:23 | denials_ | you guys appear to be running into https://bugs.launchpad.net/evergreen/+bug/883036 fwiw |
| # | 15:55:23 | pinesol_green | Launchpad bug 883036 in Evergreen "2.0-2.1-upgrade.sql script: insert or update on table "org_unit_setting_type" violates foreign key constraint "org_unit_setting_type_grp_fkey"" (affected: 1, heat: 6) [Undecided,New] |
| # | 15:56:17 | vxbush | denials_, et al: I'm willing to be a guinea pig. |
| # | 15:57:48 | tspindler has quit IRC |
| # | 15:59:54 | Meliss has quit IRC |
| # | 16:02:29 | natschil has quit IRC |
| # | 16:02:38 | denials_ | base schema for rel_2_0 creates config.org_unit_setting_type with a "grp" column |
| # | 16:03:16 | denials_ | as does the 1.6.1-2.0 upgrade script in rel_2_0. hmm |
| # | 16:04:06 | collum has quit IRC |
| # | 16:05:50 | denials_ is now known as denials |
| # | 16:05:55 | akilsdonk has quit IRC |
| # | 16:08:33 | elene has joined #evergreen |
| # | 16:10:40 | denials changes his job title to "Killer of long-lived 100% Apache processes" |
| # | 16:16:14 | shadowspar | s/Killer/Grandmaster Slayer/ |
| # | 16:19:27 | vxbush | **vxbush hands shadowspar dragon hide gloves** |
| # | 16:21:33 | denials | should probably gin up a script that checks the process list, looks for any Apache processes with > 5 minutes of processing time, and just kills them |
| # | 16:22:49 | tsbere | eeevil: My notes so far: http://egdev.mvlcstaff.org/Circ_and_Holds_Rewrite <_< |
| # | 16:46:48 | enhancin | hm, so I've got a huge query that got stuck..it's sucking up all the memory, is it bad to shut down evergreen during this time? |
| # | 16:47:03 | denials | ps -eo pid,pcpu,time,comm --sort=-pcpu | grep apache2 | perl -ane '($h,$m,$s) = split /:/, $F[2]; if (int($m) > 5 && $F[1] > 95) { kill $F[0] }' |
| # | 16:47:07 | enhancin | it's running in postgresql, but evergreen is using a ton of processor |
| # | 16:47:10 | denials | I think I'm going to cron that. |
| # | 16:48:39 | denials | enhancin: why not just kill the query? |
| # | 16:49:14 | enhancin | i'm not experienced with psql, do i do that inside of it or just kill -9 the PID of the process that is using it all? |
| # | 16:49:26 | denials | enhancin: I use pg_top (from http://ptop.projects.postgresql.org/) |
| # | 16:49:55 | denials | I wouldn't knee-jerk "kill -9" anything, that's pretty harsh |
| # | 16:50:19 | enhancin | ah, ptop is in apt-get repo : ) |
| # | 16:51:10 | denials | so "pg_top # lists postgresql processes; "k" from inside it lets you kill a given long-running process; "Q" shows you the query that's running for a given process) |
| # | 16:51:29 | denials | nothing you can't get via raw pg_statistics queries but handier |
| # | 16:52:40 | enhancin | denials: sweet, looks pretty handy. |
| # | 16:53:30 | denials | but if SELECT * FROM pg_stat_activity WHERE current_query != '<IDLE>'; floats your boat, have at it :) |
| # | 16:53:53 | enhancin | nah I use screen so i always have one window with top on anyways, I'll have another with pg_top now |
| # | 16:53:53 | gmcharlt | just as long as the end result is pg_cancel_backend(), not kill -9 |
| # | 16:53:57 | enhancin | right |
| # | 16:53:59 | csharp | argh! in my attempt to block holds on reference copies I have apparently blocked items that *aren't* reference! |
| # | 16:54:04 | enhancin | i got it, it's clearing the memory now |
| # | 16:54:23 | enhancin | interesting when a server can have 25+ load and using 12GB of it's memory and still be able to respond fairly quickly |
| # | 16:54:30 | tsbere | csharp: You get something backwards in your queries? |
| # | 16:54:34 | csharp | @hate dojo_hold_policies_interface |
| # | 16:54:34 | pinesol_green | csharp: The operation succeeded. csharp hates dojo_hold_policies_interface. |
| # | 16:54:47 | csharp | tsbere: yes apparently |
| # | 16:55:14 | tsbere | csharp: Ahh, yes, see my previous link. The first item in the "overall circ/hold stuff" group is "new editing interfaces" <_< |
| # | 16:55:22 | tsbere | Not sure *what* to use for new ones, but we need new ones. |
| # | 16:55:24 | csharp | tsbere: excellent |
| # | 16:56:42 | csharp | all I did was set reference = false where it was unset, then I made a rule... (sec...) |
| # | 16:58:19 | denials | back to django |
| # | 16:58:28 | jeff | django! |
| # | 16:59:36 | kmlussier__ has left #evergreen |
| # | 17:01:55 | csharp | I don't know what I did! |
| # | 17:02:07 | csharp shakes fists at sky |
| # | 17:04:30 | bshum | csharp: :( |
| # | 17:05:43 | bshum | So all your regular rules are ref = false |
| # | 17:05:53 | bshum | And you have deny rules setup for ref = true |
| # | 17:06:07 | csharp | I don't understand enough to know |
| # | 17:09:25 | berick | tsbere: Dyrcona: opensrf patch to prevent services dying from too-large messages. http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/perl-pipe-read-data-size |
| # | 17:10:29 | Dyrcona | ok. will give it a go tomorrow. |
| # | 17:10:49 | berick | the commit msg should spell it out pretty good. this change allowed me to delete 1k copies from the staff client. note! the request still times out in the client, because it's just too much data, but it doesn't die in the back end. |
| # | 17:11:11 | berick will open an lp ticket |
| # | 17:14:03 | jenny has joined #evergreen |
| # | 17:15:07 | berick | bug 931747 |
| # | 17:15:07 | pinesol_green | Launchpad bug 931747 in OpenSRF "Perl parent/child pipe locking IO blocks on large messages" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/931747 |
| # | 17:18:14 | Dyrcona went ahead and merged and recompiled OpenSRF so it will be ready tomorrow. |
| # | 17:23:28 | berick | Dyrcona++ |
| # | 17:24:19 | jenny has quit IRC |
| # | 17:29:56 | Dyrcona has quit IRC |
| # | 17:45:54 | vxbush has quit IRC |
| # | 19:18:01 | elene has quit IRC |
| # | 21:00:08 | luisb_ has joined #evergreen |
| # | 21:02:42 | edoceo has joined #evergreen |
| # | 21:03:16 | luisb has quit IRC |
| # | 21:03:32 | edoceo has left #evergreen |
| # | 21:04:08 | luisb_ has quit IRC |
| # | 21:41:38 | finnx has joined #evergreen |
| # | 23:40:50 | luisb has joined #evergreen |
| # | 23:45:07 | luisb has quit IRC |
April 10-13