| # | Time | Nick | Message |
|---|
| # | 07:44:20 | Sally has joined #evergreen |
| # | 08:33:04 | kmlussier has joined #evergreen |
| # | 08:44:59 | foocraft has joined #evergreen |
| # | 08:50:15 | isl-rjackson has joined #evergreen |
| # | 08:52:28 | gmcharlt has quit IRC |
| # | 08:53:27 | atheos has quit IRC |
| # | 08:53:41 | bjwebb has joined #evergreen |
| # | 08:53:41 | bjwebb has joined #evergreen |
| # | 08:56:56 | gmcharlt has joined #evergreen |
| # | 09:01:15 | isl-rjackson | Good morning Evergreen community - I have a question regarding hold requests and the field expire_time in the action.hold_request table |
| # | 09:01:52 | isl-rjackson | we have most action.hold_requests with a null expire_time - does this field come in to play on expiring old requests? |
| # | 09:02:12 | tsbere | expire_time can be set as a "don't bother filling after this date" time |
| # | 09:02:18 | tsbere | Null expire time should be "doesn't expire" |
| # | 09:02:31 | tsbere | shelf expire time is a different matter ;) |
| # | 09:03:11 | isl-rjackson | so the Library sets the expire_time when reating a hold? (sorry for the probably obvious question) |
| # | 09:03:14 | jeff | what tsbere said. expire_time is typically something seen by and settable by the patron making the hold request. it can be set to default to a certain interval, but many default it to blank/null. |
| # | 09:03:53 | tsbere | I think we have it set to default to 1 year from date placed, but the patron (or library staff) can change it. |
| # | 09:03:59 | jeff | (which means that the hold request sticks around until it is fulfilled or cancelled -- regardless of how long the patron ends up waiting for the item) |
| # | 09:04:28 | jeff | note that one of the ways that hold can be cancelled is if the system captures a hold, it sticks around on the hold shelf without being picked up, and either the system or staff cancel it. |
| # | 09:04:44 | Meliss has joined #evergreen |
| # | 09:04:49 | jeff | the system cancelling it would involve the shelf expiry that tsbere mentioned |
| # | 09:05:17 | isl-rjackson | <Jeff> In this case a library had holds awaiting pickup for a patron that had moved and wanted to know why /when they should expire |
| # | 09:05:18 | jeff | shelf expire is how long a hold waits for pickup before the system cancels the hold and moves on to the next user. |
| # | 09:05:23 | isl-rjackson | I now have an answer :-) |
| # | 09:06:00 | isl-rjackson | tsbere++ jeff++ |
| # | 09:06:03 | jeff | if you don't have shelf expiry set up and in use, then holds will wait for pickup forever, or until cancelled manually by staff. |
| # | 09:06:34 | tsbere | Technically you still have to manually trigger the expiration. <_< |
| # | 09:06:38 | isl-rjackson | <jeff> in this case the library was concerned as to why a year old hold was fulfilled |
| # | 09:06:43 | tsbere | You can just do so in bulk |
| # | 09:07:23 | jeff | tsbere: aha |
| # | 09:07:46 | jeff | i'd still like a "check in and cancel currently captured hold" workflow |
| # | 09:07:56 | jeff | as well as a "check in and agreeively attempt hold capture" |
| # | 09:07:58 | tsbere | I am trying to figure out the best way to do that |
| # | 09:08:02 | jeff | (for newly-created items) |
| # | 09:08:11 | tsbere | I am also trying to decide how to do *that* |
| # | 09:08:43 | isl-rjackson | <tsbere>: probably end up having to go the can cancel in bulk route would be my guess - leave it up to the consortium to decide! |
| # | 09:09:09 | tsbere | isl-rjackson: There is a "clear expired holds from the hold shelf"-ish option somewhere. That is the "in bulk" method. |
| # | 09:09:55 | isl-rjackson | <tsbere> isn't that for holds already captured and sitting on the shelf? |
| # | 09:10:12 | tsbere | Yes. Which is the situation I was referring to. |
| # | 09:10:29 | jeff | for aggressive hold capture, there are a few ways to optimize that require assumptions about local config/norms. it might be best to just trigger (in the generic use of the word) a re-targeting of holds on copy-available time. |
| # | 09:10:30 | tsbere | Bulk canceling holds that haven't been captured and have no expire time doesn't exist. :P |
| # | 09:10:46 | isl-rjackson | ok - my current issue from customer is regarding old holds that end up being captured and why they are still in system after a year |
| # | 09:10:49 | tsbere | jeff: I was thinking a special checkin mode for catalogers to use. ;) |
| # | 09:11:21 | tsbere | isl-rjackson: Because they weren't filled for a year, weren't canceled for a year, and otherwise were in the system for a year. The patron may still *want* the items. |
| # | 09:12:06 | isl-rjackson | <tsbere> right - just getting clarification so I can be of some help to the Libraries :-) |
| # | 09:12:13 | isl-rjackson | thanks for all the info |
| # | 09:12:38 | tsbere | isl-rjackson: Alternatively, someone decided to cheat the system by backdating a hold request by a year. |
| # | 09:16:34 | Dyrcona has joined #evergreen |
| # | 09:23:26 | tsbere is looking at code and not understanding how it works. <_< |
| # | 09:25:31 | leed has joined #evergreen |
| # | 09:42:05 | tsbere | Question about holds: What is a "Force" hold? (As in, OILS_HOLD_TYPE_FORCE, or "F" in the table)? I can't find anywhere that treats it specially, thus it appears to be a normal copy hold. (For that matter, I don't see special handling for recall "R" type either) |
| # | 09:42:08 | jeff | tsbere: alternately, trigger the aggressive capture attempt any time an item is checked in from a previous status of In Process, On Order, etc. |
| # | 09:50:01 | eeevil | F and R holds need to be improved, but F is used in open-ils.storage.action.hold_request.targetable_holds.id_list (which is used by the parallel targeter) to pull those holds first to give them priority in targeting |
| # | 09:50:47 | eeevil | for the most part, today, they are the same as C holds. nobody is funding those, so they're evolving slowly |
| # | 09:51:09 | tsbere | Ok. |
| # | 09:53:15 | eeevil | but the point is, eventually, for F holds to act like permenantly-cut_in_line holds, and R holds to do /that/ plus be put into the "Cataloging" status upon capture -- and not actually get checked out to a user. for the latter, since we have hold-base recall, that might change (not written, so subject to change) |
| # | 09:54:21 | tsbere | ok |
| # | 09:54:35 | eeevil | or, those are the original designs ... |
| # | 09:54:59 | tsbere is trying to figure out what he would need to do for a "forcibly look for a hold to be picked up here that might target this copy you just checked in" staff client feature |
| # | 09:56:11 | eeevil | approximately the F-hold design? |
| # | 09:57:00 | tsbere | In general. Intended for "you just finished cataloging this new item that no hold should have a clue about, and now you want someone to be able to pick it up off of the holds shelf without sending it into transit" type stuff. |
| # | 09:59:35 | eeevil | ahh... ok, well, that's different (based on what exists). so, I would see that as "gather all M, T and V holds for those objects that this copy attaches to, retarget them, find the "best" local hold, capture to that hold" |
| # | 10:00:43 | eeevil | of course, the "find the best local hold" part side-steps all the policy-driven logic you put so much work into (hold weighting) ;) |
| # | 10:01:21 | tsbere | Wait, I put logic into "find the best" type lookups? |
| # | 10:01:32 | tsbere | I thought I put logic into "can this even be HELD?" type lookups |
| # | 10:02:22 | eeevil | tsbere: didn't you work on the dynamic hold weighting? ah... no... sorry |
| # | 10:02:49 | eeevil | I'm conflating work on open-ils.storage.action.hold_request.nearest_hold |
| # | 10:09:13 | tsbere | I wonder if my best bet would be to add a flag somewhere to allow for *not* doing a capture attempt on retarget, then retarget any hold that could involve the copy for pickup at the current ou (and has no target already, I guess), followed by a call to nearest_hold there. |
| # | 10:10:36 | eeevil | capture attempt on retarget? |
| # | 10:10:52 | tsbere | The hold targeter looks like it attempts to find a copy for pull list use? |
| # | 10:11:04 | tsbere hasn't looked at it today, but he recalls seeing that last week |
| # | 10:11:11 | eeevil | yeah, but that's not capture, that's just targetting |
| # | 10:11:19 | eeevil | it sets current_copy |
| # | 10:11:49 | tsbere | Basically, add a flag to say "just update the list of possibles, then move on" |
| # | 10:12:01 | tsbere | Then probably just re-checkin the item, actually. |
| # | 10:12:03 | eeevil | but that's purely advisory, nearest_hold is the only thing involved in capture |
| # | 10:12:32 | hopkinsju_ has joined #evergreen |
| # | 10:12:38 | eeevil | it doesn't matter which hold says "I want that", nearest hold picks the hold to fulfill |
| # | 10:13:20 | tsbere | I figure that, at a minimum, *not* trying to set/change/whatever current_copy will shorten the return time on the calls during checkin. |
| # | 10:13:37 | eeevil | not significantly |
| # | 10:13:55 | atheos has joined #evergreen |
| # | 10:13:58 | eeevil | retargeting happens /after/ the return anyway, IIRC |
| # | 10:14:15 | hopkinsju_ has quit IRC |
| # | 10:14:22 | eeevil | we should be calling respond_complete and then tossing the holds at the targeter |
| # | 10:16:43 | tsbere looks, finds the last thing in the function is "return \@successes;" and thus assumes that there is no return before being done |
| # | 10:16:44 | eeevil | and, re my confusion about hold ordering, I have a design here that hasn't been implemented -- funding again, arg |
| # | 10:17:03 | eeevil | tsbere: that's the targeter |
| # | 10:17:16 | eeevil | that's not called directly by the staff client |
| # | 10:17:20 | kmlussier has quit IRC |
| # | 10:18:15 | tsbere | Unless there is some other function somewhere that I should be using to update the list of copies that could possibly fill a hold I may need to call that, directly or otherwise, at some point from something the staff client does. |
| # | 10:18:21 | eeevil | so, checkin does its thing and if a hold is captured then grabs the rest of the holds that the copy could have filled, uses repsond_complete, then retargets the other holds (IIRC) |
| # | 10:19:21 | tsbere | eeevil: I am looking to take a copy that, in theory, has never been looked at for a hold (because it is 5 seconds old) and find a hold that might want to capture it at the local library. Thus, I can't rely on the existing hold copy maps even *having* the copy, anywhere. |
| # | 10:19:41 | hopkinsju_ has joined #evergreen |
| # | 10:19:52 | hopkinsju_ | So which log *do* you check to see if an email notice was sent? The usual spots just show opensrf relaying to localhost. |
| # | 10:21:25 | eeevil | right, so, checkin doesn't help you, and I thought you were talking about checking the item in ... this would require ML work, I imagine, to gather the list of holds touching the copy-associated object, and then call a higher-level (open-ils.circ, probably) method to retarget those holds, by id |
| # | 10:21:26 | tsbere | hopkinsju_: Depends on your mailer. And a pile of other fun. |
| # | 10:22:37 | tsbere | eeevil: I am looking to change checkin to have a "check in without capturing holds/transits, forcibly look for local holds to retarget, then check in again while capturing holds/transits" mode. |
| # | 10:23:54 | hopkinsju_ | tsbere: Yeah, this type of fun falls into the "not on my day off" pile |
| # | 10:25:33 | eeevil | tsbere: IMO, a "retarget holds that touch thing that this copy touches" method would be far simpler, and could just be run /before/ checkin, and then just use regular checkin |
| # | 10:25:36 | eeevil | no? |
| # | 10:26:12 | tsbere | eeevil: Still need a way to trigger that, though. |
| # | 10:27:10 | eeevil | and then you have a new, separate tool for retargeting holds when, say, a missing copy is found ... IMO, that would be far preferable to embedding more logic in checkin (which is super-complicated already) ... but, just my opinion :) |
| # | 10:28:13 | tsbere | Whether I do this at the staff client level, the perl level, or whatever, I still need a way to do the actual retarteting call. Which will likely be a two or three call sequence to avoid duplicating some logic. |
| # | 10:28:28 | eeevil | you can use that method when you notice the initial status of the copy is not holdable (or its age is below some threshold), and elsewhere |
| # | 10:29:02 | eeevil | just use the targeter |
| # | 10:29:19 | raynerj has joined #evergreen |
| # | 10:29:49 | tsbere | Doesn't the targeter takes single hold ids or "go get anything you haven't touched in the past interval (12 hours if not specified)"? Thus I need to collect IDs first either way. |
| # | 10:29:51 | eeevil | tsbere: so, you can pass one hold, or an array of holds, to the targeter. that's what you should do |
| # | 10:30:00 | eeevil | yes |
| # | 10:30:08 | eeevil | you do have to collect the holds |
| # | 10:30:20 | tsbere | I need "call 1: Get hold ids that are tied to this bib at this library. call 2: retarget said holds" at a min |
| # | 10:30:21 | eeevil | which I said up there ^ ;) |
| # | 10:30:47 | tsbere said he would likely need a two or three call sequence up there too |
| # | 10:35:45 | foocraft has quit IRC |
| # | 10:45:02 | foocraft has joined #evergreen |
| # | 10:50:53 | Dyrcona | isn't there an open-il.circ retarget holds or something or other. I seem to recall seeing something like that last time I was browsing Holds.pm. |
| # | 10:55:44 | hopkinsju_ has quit IRC |
| # | 11:01:50 | kmlussier has joined #evergreen |
| # | 11:04:55 | bshum | Is there any downside to changing the block_list values in config.standing_penalty? Like removing HOLD from the block actions for exceeding fines. |
| # | 11:05:22 | bshum | Thinking that removing the value would allow holds to be placed even if a patron exceeds fines, in that particular example. |
| # | 11:09:59 | Dyrcona | bshum: I've done that very thing at the request of our members' staff. Everything works as we expected. |
| # | 11:10:38 | bshum | Dyrcona: Same here, apparently it "worked differently" in "the old system" |
| # | 11:10:45 | bshum | Thanks. |
| # | 11:18:56 | artunit has quit IRC |
| # | 11:19:01 | artunit_ has joined #evergreen |
| # | 11:19:02 | artunit_ is now known as artunit |
| # | 11:23:17 | youdonotexist has joined #evergreen |
| # | 11:24:49 | artunit has quit IRC |
| # | 11:25:06 | artunit has joined #evergreen |
| # | 11:27:05 | artunit has quit IRC |
| # | 11:27:16 | artunit has joined #evergreen |
| # | 12:18:50 | bshum | Hmm, anyone else get dojo interfaces where trying to click on a target results in a display window that scrolls forever out of shape and never allows you to reach the Save / Cancel options at the bottom? Guessing it's some weird bug in our display. :( |
| # | 12:19:02 | bshum | Trying to pull up a specific Acq Provider |
| # | 12:19:08 | bshum | For example |
| # | 12:22:20 | senator | bshum: it's not just you |
| # | 12:22:21 | senator | i've seen that |
| # | 12:22:57 | senator | and i see it specifically where you point it out, too |
| # | 12:23:07 | senator | if you want to craft a fix/workaround of sorts, |
| # | 12:23:12 | senator | here's what you need: |
| # | 12:23:24 | senator | *rummages* |
| # | 12:24:19 | senator | editStyle="pane" |
| # | 12:24:44 | senator | set that attribute on the DOM element that holds the autogrid in the relevant tt2 file |
| # | 12:25:11 | senator | grumble grumble dijit grumble grumble 1.3 |
| # | 12:25:31 | phasefx | auto scroll is evil too, within staff client. I've seen those creep back in |
| # | 12:26:08 | senator | i hate that too. i don't think we really completely fixed it. we figured out how to deal with a given widget but not yet how to apply it broadly |
| # | 12:26:51 | bshum | senator: Nifty! Thanks for the tips, I'll poke at the TT file to see how that works. Never examined one closely before... |
| # | 12:30:34 | bshum | I'm also trying to see why that particular interface isn't showing providers per org unit when logged in with an acq user of a specific library. |
| # | 12:30:50 | bshum | For some reason, it just hides all the providers not owned by that lib |
| # | 12:31:07 | bshum | But you have to scroll through a couple Next, next screens to get to a screen that does show the providers. |
| # | 12:31:14 | bshum | So they're just hidden strangely |
| # | 12:31:50 | senator | bshum: probably no good reason. please be bold with any user experience improvements you can make. we certainly need them :-) |
| # | 12:32:24 | tsbere | You should see some of our list |
| # | 12:40:57 | tsbere still has no clue how *one* workstation was missing fields that no other workstation was missing |
| # | 12:44:39 | tspindler has joined #evergreen |
| # | 12:57:47 | bshum | senator: Will do, thanks for putting me on the right path. |
| # | 13:08:38 | foocraft has quit IRC |
| # | 13:13:39 | denials is going to be on the road for the community meeting at 2:00 EST - I'll try to pull over and join in, but can't guarantee connectivity |
| # | 13:14:27 | denials | not sure if somebody wants to try and draft dev & governance reports? |
| # | 13:15:23 | denials | might be worthwhile rallying around the release team for coordinating the various bits (and maybe pulling bjwebb into the convo for what his packaging stuff can help automate on the release tarball generation side?) |
| # | 13:16:12 | denials | e.g. would be nice to see his packaging stuff go into the /build/ subdir and get to the point of release cutting = "point a script at a given git tag and watch the RPMs/DEBs come out the other side" |
| # | 13:16:16 | denials scoots |
| # | 13:17:49 | bjwebb | denials: yeah, i did wonder about this myself |
| # | 13:28:40 | bshum | denials: afterl says she'll take care of governance report. |
| # | 13:28:58 | tspindler has quit IRC |
| # | 13:49:17 | pinesol_green has joined #evergreen |
| # | 13:50:32 | pinesol_green has joined #evergreen |
| # | 13:58:44 | afterl has joined #evergreen |
| # | 13:59:03 | pinesol_green has joined #evergreen |
| # | 14:00:26 | bshum | 2 pm. Community Meeting time. |
| # | 14:01:07 | bshum | http://evergreen-ils.org/dokuwiki/doku.php?id=community:meetings:2011-07-08 |
| # | 14:01:30 | bshum | It's a short agenda today, but guess we can start with intros / volunteers to see if we have enough folks to have a meeting at all. |
| # | 14:01:50 | bshum is Ben Shum, Bibliomation |
| # | 14:02:16 | denials is on the side of the road |
| # | 14:02:21 | afterl is Amy Terlaga, Bibliomation |
| # | 14:02:24 | bshum | denials++ :) |
| # | 14:03:38 | brian_f has joined #evergreen |
| # | 14:04:04 | brian_f is Brian Feifarek |
| # | 14:04:21 | denials is Dan Scott |
| # | 14:04:35 | bshum | Pretty quiet this afternoon. If we don't have too many reps show up, perhaps we should postpone or reschedule the community meeting. |
| # | 14:04:42 | kmlussier is Kathy Lussier, MassLNC |
| # | 14:04:50 | bshum | Or post report links to the meeting page. |
| # | 14:05:52 | denials | FWIW, last governance committee meeting minutes (thanks to afterl) are at http://git.evergreen-ils.org/?p=contrib/governance.git;a=blob_plain;f=minutes/2011-06-21.txt;hb=HEAD |
| # | 14:06:06 | afterl | Oh, denials, you stole my thunder |
| # | 14:06:18 | afterl | but thanks for the credit |
| # | 14:06:39 | brian_f | throw a thunderbolt his way |
| # | 14:06:47 | Stareagle has joined #evergreen |
| # | 14:06:51 | phasefx is Jason Etheridge, Equinox |
| # | 14:07:01 | bshum | 6 folks so far, and otherwise quiet. Should we reschedule? |
| # | 14:07:51 | afterl | We just had committee reports anyway right? |
| # | 14:07:56 | kmlussier | Might not be a bad idea to reschedule. |
| # | 14:08:02 | brian_f | I think that would make sense |
| # | 14:08:34 | bshum | afterl: Yeah. |
| # | 14:08:50 | afterl | Yes, sounds good |
| # | 14:08:53 | denials | With respect to the Governance minutes, and the concern about release quality, I had mentioned earlier today on IRC that maybe we could lean on the Release Team to come up with some ideas? |
| # | 14:10:08 | denials | e.g. with the 2.0.7 release and the 2.1 RC1 release we had some oopses that we could learn from and add to the release process |
| # | 14:10:27 | brian_f | denials ++ seems like bjwebb's packaging can help quite a bit as you said on IRC |
| # | 14:12:03 | denials | whether that's more automation of the packaging step (go bjwebb go!) or more automated tests (figuring out how to know that a given i18n language isn't busted) or more communication & human power (proof-reading release announcements & adding more content to release notes, etc) |
| # | 14:12:25 | denials | anyway - I'm roasting on the side of the road :) |
| # | 14:12:27 | bshum | So, how about let's postpone this meeting officially, and ask each committee to put their info on the page and we reconvene again later (maybe next month?) |
| # | 14:12:35 | bshum | denials++ for roadside thoughts |
| # | 14:12:50 | denials | bshum: okay |
| # | 14:12:58 | bshum | Though we should start a broader discussion about release team efforts I think. |
| # | 14:13:02 | bshum | New listserv! |
| # | 14:13:03 | brian_f | bshum++ |
| # | 14:13:28 | brian_f | ++ on both postpone and release efforts |
| # | 14:13:36 | denials | (oh, and beefing up the asciidoc README to single-source docs is another way to simplify / automate the release efforts... the master README is almost there, I think) |
| # | 14:13:49 | bshum | +1 to single-source install doc |
| # | 14:13:50 | denials | okay, time to get this car back in gear and the AC on |
| # | 14:13:57 | afterl | denials: be cool |
| # | 14:14:02 | bshum | Alright, thanks everyone, we'll try this again next time :) |
| # | 14:14:09 | denials | thanks bshum++ for organizing / wrangling |
| # | 14:14:15 | bshum hits record for shortest meeting EVER! |
| # | 14:14:15 | denials | afterl++ lol |
| # | 14:14:24 | kmlussier | bshum++ |
| # | 14:14:29 | Stareagle has quit IRC |
| # | 14:14:37 | afterl | bye, all |
| # | 14:14:47 | denials scoots |
| # | 14:16:35 | jeff | are there any community demo/test servers out there with more than just a meager collection of dummy circs / patrons? |
| # | 14:17:18 | jeff | i have a reporting experiment to share, and while i can certainly fake up some data, i'd be just as happy to use existing test data. |
| # | 14:17:27 | bjwebb reads scrollback |
| # | 14:17:31 | brian_f | jeff: I don't think there are, but it would be good to be able to have that |
| # | 14:17:48 | bjwebb | yeah, i'd certainly be interested in some good dummy data for what i'm doing |
| # | 14:17:58 | brian_f | jeff: what kind of experiment do you have? |
| # | 14:18:48 | phasefx has an old script on the wiki for generating patron data |
| # | 14:19:37 | berick uses that script all the time fwiw |
| # | 14:19:42 | berick | and the holdings data script |
| # | 14:20:41 | brian_f | that script would be great to have at hand (if I could find it...) |
| # | 14:21:07 | berick | brian_f: http://evergreen-ils.org/dokuwiki/doku.php?id=advocacy:demonstration_data |
| # | 14:21:39 | brian_f | berick: Thanks! the Google search wasn't getting me there very quickly |
| # | 14:22:36 | brian_f | btw, is there a search tool for these IRC logs? I haven't bumped into one |
| # | 14:22:56 | phasefx | they're supposed to indexed by the google custom search engine used on the website |
| # | 14:24:53 | brian_f | Ah, I'll try some obscure search terms in there to test |
| # | 14:26:08 | jeff | phasefx++ berick++ |
| # | 14:27:36 | jeff | brian_f: i've been using some reporting tools from Jaspersoft to report against some dev/test, and now live Evergreen data. I'm gathering things to show what the self-service interface looks like, and to see who else is interested in experimenting. |
| # | 14:29:03 | jeff | the tools come in community/gpl'd versions and a commercial version. so far, i'm focusing on what's possible with the community/gpl'd edition. |
| # | 14:29:36 | brian_f | jeff: Interesting-- I'll take a look too. I wonder if pentaho could be similar; they also have a community version. |
| # | 14:29:50 | jeff | but i can see where some interested libraries might opt for the commercial addition on top. |
| # | 14:30:41 | jeff | brian_f: i had looked briefly at pentaho. do you have experience with it? |
| # | 14:31:42 | brian_f | jeff: no I don't have experience; just bumped into it and thought it could be useful. having a free option too makes it more generally appealing. hopefully installation is easy |
| # | 14:42:54 | csharp | does anyone have any documentation out there about LAN setups for libraries running Evergreen? Like a minimum bandwidth recommendation, etc.? |
| # | 14:44:02 | csharp | we have several libraries who are having serious slowness when their bandwidth is saturated and wanted to be able to recommend a minimum |
| # | 14:44:45 | bshum | csharp: If you find that out, I'd be curious to know too. Slowness is a problem and we're definitely narrowing it to bandwidths too. |
| # | 14:44:50 | bshum | (among other things) |
| # | 14:47:03 | csharp | we've been recommending traffic shaping/segregating EG workstations from the public net, etc. but there are some that still suffer (not having much in the way of tech expertise/resources) |
| # | 14:48:04 | Dyrcona has quit IRC |
| # | 14:52:45 | jeffdavis has quit IRC |
| # | 14:57:46 | jeff | csharp: depending on their budgets, you might consider throwing something like m0n0wall on a handy PC or Soekris box to do the traffic shaping. |
| # | 14:58:27 | jeff | that may be more support than you are prepared to provide. |
| # | 15:00:10 | jeff | evergreen is rarely bandwidth intensive, but a saturated pipe at the library will result in packet loss and latency, which will drag performance down. |
| # | 15:01:04 | tsbere | We have a dedicated network link installed in most of our member libraries just for staff use. |
| # | 15:03:23 | jeff | how large are these libraries, and what is the nature (speed/etc) of the dedicated link? |
| # | 15:04:01 | tsbere | Size varies greatly. Dedicated link is now a cable connection. |
| # | 15:04:25 | kuys_ has joined #evergreen |
| # | 15:04:38 | tsbere | Note that when I say dedicated I mean "to the staff computers for internet everything", not "to us only" |
| # | 15:06:14 | kuys_ | Well, I'm back, Debian is a nogo I'm almost certain i'm the culprit |
| # | 15:06:21 | kuys_ | here is the error message root@evergreen:/etc/init.d# ejabberd stop {error_logger,{{2011,7,8},{14,2,9}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} {error_logger,{{2011,7,8},{14,2,9}},crash_report,[[{initial_call, |
| # | 15:06:31 | kuys_ | well doesn't look like I can fit it all |
| # | 15:06:59 | bshum | jeff: In our case, one of the libraries that encountered slowness metered out at an upload of 73 kb/sec and 1-2 mb/sec download. We were using iperf to test the connection speed between a client machine and our Evergreen server. |
| # | 15:07:10 | bshum | jeff: Course that was over DSL and they are a "big" library. |
| # | 15:07:27 | kuys_ | root@evergreen:/etc/init.d# ejabberd stop {error_logger,{{2011,7,8},{14,2,9}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]} {error_logger,{{2011,7,8},{14,2,9}},crash_report,[[{initial_call,{net_kernel,init,['Argumen |
| # | 15:07:30 | bshum | jeff: We assumed that to mean they needed to work out better network connections. |
| # | 15:07:41 | kuys_ | {registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{ancestors,[net_sup,kernel_sup,<0.9.0>]},{messages,[]},{links,[#Port<0.105>,<0.17.0>]},{dictionary,[{longnames,false}]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,463}],[]]} |
| # | 15:07:54 | kuys_ | {error_logger,{{2011,7,8},{14,2,9}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfargs,{net_kernel,start_link,[[ejabberd,shortnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2011,7,8}, |
| # | 15:08:05 | kuys_ | {14,2,9}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2011,7,8},{14,2,9}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} |
| # | 15:08:17 | kuys_ | {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} Crash dump was written to: /var/log/ejabberd/erl_crash.dump |
| # | 15:08:35 | bshum | kuys_: For big pastes, might I suggest that you try using a paste tool. Perhaps like pastie.org since the two links at the top aren't working it seems... |
| # | 15:08:56 | kuys_ | ok i appologize |
| # | 15:08:57 | Sally has quit IRC |
| # | 15:10:02 | jeff | bshum: if iperf was showing an upstream of 73 kbit/sec, it sounds like it was almost certainly saturated. |
| # | 15:10:02 | kuys_ | http://www.pastie.org/2184345 |
| # | 15:10:06 | kuys_ | again i am sorry |
| # | 15:11:15 | bshum | kuys_: It's okay, just hard to read in channel :) |
| # | 15:11:44 | bshum | jeff: That was our best guess. We're still collecting information from our libraries on "the slowness problem" |
| # | 15:11:56 | jeff | kuys_: can you pastebin your ejabberd.cfg file? |
| # | 15:12:19 | jeff | kuys_: have you made changes to ejabberd other than to the ejabberd.cfg file? |
| # | 15:12:27 | Dyrcona has joined #evergreen |
| # | 15:15:29 | bshum | kuys_: Huh, are you inside the /etc/init.d/ directory when you call "ejabberd stop" command? |
| # | 15:16:08 | bshum | Perhaps you should try the full path of the command "/etc/init.d/ejabberd stop" as a single action. |
| # | 15:16:26 | bshum | Did what it looked like and got strange, strange errors. |
| # | 15:17:40 | jeff | bshum++ |
| # | 15:18:10 | jeff | kuys_: ignore my request -- i believe bshum has your problem. try "/etc/init.d/ejabberd stop" instead of "ejabberd stop" |
| # | 15:19:02 | bshum | I want to add the MARC plugin to pinesol |
| # | 15:19:12 | jeff | (the difference between running the "init script" that starts/stops a daemon like ejabberd, and trying to run the daemon itself) |
| # | 15:19:12 | bshum | I saw the Koha folks have it, I'm jealous. |
| # | 15:19:32 | jeff | bshum: zoia has it. it can be useful at times. |
| # | 15:20:06 | bshum | jeff: It looked nifty. Should find out what other plugins could be handy for pinesol |
| # | 15:37:38 | youdonotexist has quit IRC |
| # | 15:37:56 | youdonotexist has joined #evergreen |
| # | 15:46:25 | jeff | phasefx, berick, all: anyone have a "generate fake circs" script yet? if not, I'll give it a shot. |
| # | 15:46:51 | berick | jeff: not that I know of |
| # | 15:49:11 | csharp | jeff: sorry - I asked and ran ;-) - the libraries are on a shared network of T1s mainly (there are efforts underway to upgrade the whole thing)... connection speeds vary widely depending on the areas of service (much lower than necessary for all the devices trying to push a signal through, though) |
| # | 15:51:55 | kuys | sorry for the late reply |
| # | 15:52:02 | kuys | my director has me doing 100 things |
| # | 15:52:10 | kuys | but yes that was the error |
| # | 15:52:43 | kuys | I was stopping ejabberd from the /etc/init.d/ directory and it was crashing |
| # | 15:52:57 | kuys | did it from / with /etc/init.d/ejabberd sotp |
| # | 15:53:00 | kuys | stop* |
| # | 15:53:02 | kuys | no problems |
| # | 15:53:03 | kuys | thanks all |
| # | 15:54:12 | bshum | kuys: Cool deal, happy installing :) |
| # | 15:56:48 | kuys | Another question; Does anyone in here have experience Migrating for Mandarin ILS to Evergreen? Is so, How did the project go? |
| # | 15:57:00 | Meliss has quit IRC |
| # | 15:57:47 | jeff | kuys: for future reference, even if you're in the /etc/init.d directory, TYPICALLY running "ejabberd" will typically not run the executable in the current directory, it'll look elsewhere in your path first. |
| # | 15:58:15 | jeff | kuys: you can say "run the executable/script in the current directory with "./ejabberd" instead of just "ejabberd" |
| # | 15:58:59 | kuys | ah thank you, that is good to know |
| # | 15:59:59 | jeff | there are various reasons, but one is that this prevents a malicious user from putting an executable named "ls" in a random dir like /tmp |
| # | 16:00:46 | jeff | "cd /tmp" followed by "ls" would then do something malicious -- better in that case to find /bin/ls first, and often to not even have the current directory anywhere in the path. |
| # | 16:04:01 | Dyrcona | Yeah, winderz is broke like that. :) |
| # | 16:24:47 | isl-rjackson has quit IRC |
| # | 16:31:05 | gdunbar has quit IRC |
| # | 16:32:47 | raynerj has left #evergreen |
| # | 16:53:56 | kmlussier has quit IRC |
| # | 17:04:11 | afterl has quit IRC |
| # | 17:09:20 | lisppaste has joined #evergreen |
| # | 17:27:42 | bshum | lisppaste++ |
| # | 17:27:56 | bshum | It lives!! |
| # | 17:29:30 | Dyrcona has quit IRC |
| # | 17:39:20 | sal_ has joined #evergreen |
| # | 17:42:26 | sal_ | Hi. Trying to install 2.0.7 on Ubuntu 10.10 (so I could eventually play with new SIP 37/38), and seem to have screwed something up doing the install. Troubleshooting fine up to start-c step, then get errors in osrfsys.log. |
| # | 17:43:39 | sal_ | errors are all osrfsys.log:open-ils.pcrud... something is composite type or relation does not exist |
| # | 17:44:18 | sal_ | (Annoyingly, didn't notice until I was trying to create the SIP permission group through client--everything seems to run fine.) |
| # | 18:00:48 | sal_ has quit IRC |
| # | 18:50:14 | jamesrf | kuys: Sitka has done lots of Mandarin migrations, many have gone better than some of the other ILSes we've migrated :) |
| # | 19:07:39 | youdonotexist has quit IRC |
| # | 20:13:34 | eeevil | @later tell sal_ those are normal log lines, just ignore them |
| # | 20:13:34 | pinesol_green | eeevil: The operation succeeded. |
| # | 20:32:56 | brian_f has quit IRC |
April 10-13