| Time |
Nick |
Message |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 08:18 |
|
ngf42 joined #evergreen |
| 08:38 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:56 |
|
kmlussier joined #evergreen |
| 09:13 |
|
mmorgan1 joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:33 |
gmcharlt |
@quote random |
| 09:33 |
pinesol_green |
gmcharlt: Quote #84: "pinesol_green grabs some Cookies and Cream Ice Cream for Mr. Spock: Something fascinating just happened." (added by bshum at 06:11 PM, May 10, 2014) |
| 09:35 |
kmlussier |
heh |
| 09:36 |
kmlussier |
miker / berick: the purpose of config.display_field_map is to give the display field a name that can then be used in tt2 templates and elsewhere? Am I understanding that correctly? |
| 09:46 |
|
agoben joined #evergreen |
| 09:51 |
miker |
kmlussier: yes, that's the main practical reason. it lets us say "this index def is used to extract the data for 'title' displays", for instance, when there may be several title-related defs, perhaps even overlapping |
| 09:54 |
kmlussier |
miker: OK, thanks! I have another question. I was looking at the contents.tt2 file in your branch, where I see things like display_field => 'toc' are added, but the xpath => '//*[@tag="505"]' is also still there. Is that still needed if we're defining what toc means in the database? |
| 09:56 |
miker |
kmlussier: if, for some reason, the display field does not extract the 'toc' data, it can fall back to the in-template extraction. for now. example: the display field index def is more strict about required indicators, so it doesn't extract "incorrectly" cataloged data |
| 09:56 |
miker |
I should say, "IF the display field..." |
| 09:57 |
kmlussier |
miker: Ah, I see. Makes sense. Thanks! |
| 09:57 |
kmlussier |
miker++ |
| 09:58 |
|
mmorgan1 joined #evergreen |
| 09:58 |
miker |
also, generally speaking, the index defs use a mods-transformed version of the record (because that does stuff like normalize punctuation, and apply other ISBD rules, that are impossible with pure xpath over marcxml) |
| 09:59 |
miker |
so we can look at the pure-marc, in-template stuff as best effort, rather than best displayable version |
| 10:03 |
gmcharlt |
berick: (et al.) wanted to mention an idea that's been percolating recently |
| 10:04 |
gmcharlt |
namely, adding a method to open-ils.auth_internal to generate a session for an arbitrary user ID |
| 10:05 |
gmcharlt |
initial use case is for writing an A/T reactor that can renew loans without having to know the user's password and without having to change a lot of the circ run_method's internals |
| 10:05 |
gmcharlt |
but could also be used by cronjobs that currently require username and password to act as a specific staff user |
| 10:06 |
gmcharlt |
the idea is that such sessions would require a nonce to be set and passed to them each time they're requested so that they can't slip out (easily) to act as public-client-facing sessions |
| 10:08 |
berick |
gmcharlt: i think you can already do that. |
| 10:09 |
gmcharlt |
ah, that would save some time! :) |
| 10:09 |
miker |
ORLY? |
| 10:09 |
* miker |
looks... |
| 10:09 |
jeff |
gmcharlt: can you elaborate on how the nonce makes it "so that they can't slip out (easily) to act as public-client-facing sessions"? |
| 10:09 |
berick |
i did something similer recently. created a new password type for a vendor. created a session via auth-internal |
| 10:10 |
gmcharlt |
berick: open-ils.auth_internal.session.create? |
| 10:10 |
berick |
gmcharlt: yep |
| 10:10 |
jeff |
gmcharlt: i'm not following the risk or the way the nonce mitigates, but I'm not sure if it's the short summary or me not having percolated on it as much yet. :-) |
| 10:12 |
gmcharlt |
jeff: the idea being that you'd have to know both nonce and session ID to access the session; risk being (a small, theoretical one) auth sessions that were created being used by outsiders |
| 10:12 |
gmcharlt |
of course, if you can get to open-ils.auth_internal in the first place, the jig is already up |
| 10:13 |
berick |
yeah, you have cstore there |
| 10:13 |
gmcharlt |
more generally, notion would be binding a session to a specific client/use-context |
| 10:13 |
gmcharlt |
checking and verifying the ingress might help with that as well |
| 10:13 |
gmcharlt |
all of that said... I may well be over-thinking it |
| 10:14 |
jeff |
are you proposing that you'd have to pass something extra in any method call where you'd normally pass an auth token, or am i incorrect in thinking that your proposed auth_internal method would return an auth token? |
| 10:15 |
miker |
jeff: that's the original idea, yes |
| 10:16 |
miker |
pass [$token,$nonce] rather than $token ... since it's just a scalar everywhere that should be transparent, and then if the session (in memcache) has a nonce, you'd have to pass the same nonce to be able to retrieve it |
| 10:16 |
jeff |
and if the nonce were concatenated it wouldn't break or require -- yeah, got it. |
| 10:18 |
miker |
but, since auth_internal is already doing what's needed... |
| 10:52 |
miker |
berick (or anyone): anybody seeing spinning websockets apache backends occasionally? It looks like an inf loop in one of the threads ... I half-suspect the ejabberd side is being disconnected and the thread that listens for messages there goes crazy. I'm currently giving the side-eye to a (theoretical) potential for a tight loop at lines 340-350 in osrf_websocket_translator.c |
| 10:54 |
|
derekz joined #evergreen |
| 10:58 |
|
jvwoolf joined #evergreen |
| 10:58 |
berick |
miker: i haven't, but that seems like a likely cause. curious if you can capture an strace.. |
| 10:58 |
berick |
in any event, a check in that loops seems like a good addition |
| 11:03 |
|
Christineb joined #evergreen |
| 11:07 |
berick |
basically the outbound analog to bug 1744158 |
| 11:07 |
pinesol_green |
Launchpad bug 1744158 in OpenSRF "osrf_websocket_translator send requests to the bit-bucket" [Undecided,Confirmed] https://launchpad.net/bugs/1744158 |
| 11:08 |
dbwells |
miker: we've seen it twice since we upgraded in late December, but I've got nothing useful to add. Just confirmation. |
| 11:09 |
|
mmorgan joined #evergreen |
| 11:10 |
miker |
berick: strace shows either, waiting on a futex (how the threads decide who's allowed to use our non-reentrant functions at a given moment), or nothing at all (spinning in user-mode code, no system calls going on) |
| 11:15 |
|
collum joined #evergreen |
| 11:17 |
berick |
miker: thanks |
| 11:19 |
miker |
well... "thanks", maybe ... :) not a lot to go on. since we just get tmsg, or not, I guess we'll have to go scrobling through the opensrf client object to find the socket and test connectedness |
| 11:23 |
berick |
one thing that's telling is the lack of a select(..) in the strace. could be short-circuiting before that normally fires... |
| 11:27 |
miker |
that was my thought. a deep check that says "well, we can't do anything, return now!" |
| 11:28 |
miker |
I've traced the code and didn't see a code comment to that effect, nor spot an obvious implementation ... but I was looking quickly |
| 12:00 |
|
khuckins joined #evergreen |
| 12:03 |
|
rlefaive joined #evergreen |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:24 |
|
abowling joined #evergreen |
| 12:25 |
|
JBoyer joined #evergreen |
| 12:26 |
|
khuckins_ joined #evergreen |
| 12:58 |
|
jwoodard joined #evergreen |
| 13:08 |
Dyrcona |
@marc 050 |
| 13:08 |
pinesol_green |
Dyrcona: A classification or call number that is taken from Library of Congress Classification or LC Classification Additions and Changes. The brackets that customarily surround alternate class/call numbers are not carried in the MARC record; they may be generated based on the presence of repeated $a subfields. (Repeatable) [a,b,3,6,8] |
| 13:13 |
berick |
miker: fyi, put this together. checking now to make sure it doesn't break anything. |
| 13:13 |
berick |
http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/ws-gateway-connection-check |
| 13:15 |
berick |
difficult to confirm the actual bug though because the timing has to be just so... |
| 13:17 |
berick |
jabber has to go away between request and response. |
| 13:22 |
csharp |
miker: yes, I've seen the waiting for futex straces on high-load apache2-websockets procs |
| 13:22 |
* csharp |
may even be able to find them now |
| 13:27 |
* miker |
reads up |
| 13:28 |
miker |
berick: ooo... you could use the new open-ils.slooooooooow app to test that! just kill ejabberd after the request goes to the server, perhaps |
| 13:30 |
berick |
miker: yeah.. that rings a bell. /me looks |
| 13:32 |
csharp |
yeah, we have those raising system load on all of our app bricks |
| 13:33 |
csharp |
(just to confirm) |
| 13:33 |
miker |
csharp: if they're just sitting at the top of top for forever, it's safe to kill them, btw |
| 13:33 |
berick |
miker: where is said app? not seeing anything obvious |
| 13:34 |
miker |
mmmm.... sec |
| 13:34 |
csharp |
miker: thanks |
| 13:36 |
abowling |
anyone know *why* this command "yaz-marcdump -f marc-8 -t utf-8 -o marcxml foo.mrc > bar.xml" would create a file that ends up as ISO-8859? |
| 13:36 |
miker |
berick: ah, it's an opensrf app ... and not merged to master yet. but you can still grab it, it's trivial: http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=commitdiff;h=e22ad9c17d6b90204001096752c99fa2234eedbd |
| 13:36 |
berick |
thanks miker |
| 13:37 |
miker |
abowling: I think utf-8 is spelled utf8 (and marc-8 as marc8), per http://www.indexdata.com/yaz/doc/yaz-iconv.html |
| 13:39 |
miker |
the -t might default to your local default encoding if it doesn't recognize what you give it... this is all just a guess, mind |
| 13:40 |
csharp |
@eightball will there be a new OpenSRF version released soon? |
| 13:40 |
pinesol_green |
csharp: Come again? |
| 13:41 |
berick |
miker: just added a sleep to patron search.. fix confirmed. now I just need to confirm the original bug w/o the fix. |
| 13:43 |
|
mmorgan1 joined #evergreen |
| 13:43 |
miker |
berick++ |
| 13:44 |
abowling |
thanks, miker. it was actually dumber (on the user's part) than that. my script didn't specify "-f" at all. |
| 13:44 |
abowling |
marc-8 and marc8 seem to work equally successfully when i actually include them. :) |
| 13:45 |
abowling |
miker++ |
| 13:45 |
miker |
yeah, yaz may be smart enough to remove "-"s since they'd be common... unsure |
| 13:46 |
abowling |
so i've learned that entering "-t utf-8" is ignored without the "-f", as you wrote ^ |
| 13:46 |
miker |
ah, interesting. "tell me everything or I hear nothing!" |
| 13:47 |
abowling |
yep! |
| 13:48 |
* Dyrcona |
thinks yaz_marcdump won't guess the input encoding and therefore drops the output encoding. |
| 13:48 |
Dyrcona |
Which leads to the supposition that you actually have ISO8859-1 input records. |
| 13:50 |
berick |
miker: csharp: issue and fix confirmed. i'll open an LP. |
| 13:50 |
csharp |
berick++ |
| 13:50 |
* berick |
has spinny websockets |
| 13:50 |
* csharp |
breathes a sigh of relief |
| 13:50 |
Dyrcona |
berick++ |
| 13:51 |
csharp |
also glad I didn't try anything too crazy to address it - I've been hanging back and observing things without making server changes |
| 13:51 |
* Dyrcona |
missed the details, so will be happy to read the bug description. |
| 13:51 |
csharp |
trying to get a good idea of what web sockets is going to do in the long term |
| 13:52 |
csharp |
Dyrcona: tl;dr: spinning apache-websockets processes waiting for children to finish who are never coming home :-/ |
| 13:52 |
berick |
because the bridge was burned |
| 13:52 |
Dyrcona |
Sounds bad... |
| 13:53 |
Dyrcona |
I haven't seen that, but we're not using the web client seriously, yet. |
| 14:42 |
JBoyer |
berick, I've noticed this type of spinning on regular non-websocket connections, do you think it will address those also or is this change fairly specific to WS connections? (I haven't had a chance to look at the patch) |
| 14:44 |
berick |
JBoyer: my patch is specific to websockets |
| 14:47 |
|
rlefaive joined #evergreen |
| 14:48 |
Dyrcona |
And, git saves the day, again! |
| 14:48 |
Dyrcona |
git++ |
| 14:51 |
JBoyer |
berick++ |
| 14:52 |
JBoyer |
I'll see if I can track down any of those to see what may be happening. (Last time dbs mentioned that libraries that are never open can cause that kind of spinning and fixing a couple of them did drop the count a good deal) |
| 15:25 |
Dyrcona |
@karma |
| 15:25 |
pinesol_green |
Dyrcona: Highest karma: "gmcharlt" (236), "berick" (158), "kmlussier" (140), "Dyrcona" (106), and "csharp" (82). Lowest karma: "comcast" (-27), "systemd" (-10), "^" (-8), "oracle" (-7), and "ie" (-6). You (Dyrcona) are ranked 4 out of 225. |
| 15:26 |
csharp |
comcast-- |
| 15:26 |
csharp |
comcast-- |
| 15:26 |
csharp |
comcast-- |
| 15:26 |
csharp |
comcast-- |
| 15:28 |
Dyrcona |
heh |
| 15:43 |
Bmagic |
berick: I'm trying to figure out why invoices coming back from INGRAM are not populating/connecting back to the line item. I have an example where it worked in October. The difference that I can find has to do with RFF+LI |
| 15:44 |
Bmagic |
I can see that ORDERS from the good* example contain something like RFF+LI:3186/53669 |
| 15:45 |
Bmagic |
where the bad* one has 'RFF+LI:ING 11/29/17 Books Adu' |
| 15:45 |
Bmagic |
could it be that the reason that the invoices are failing is due to the way the order EDI message is constructed? |
| 15:53 |
jwoodard |
maybe I am missing it but is there a way to import a csv list of patrons into a bucket? |
| 15:54 |
jwoodard |
on the webclient |
| 15:56 |
kmlussier |
comcast-- |
| 16:15 |
miker |
jwoodard: yes, on the pending users tab. then you transfer them to a bucket (or create a new one) |
| 16:15 |
jwoodard |
i just found it lol |
| 16:15 |
jwoodard |
right as you message popped up |
| 16:15 |
jwoodard |
thanks! |
| 16:22 |
|
khuckins_ joined #evergreen |
| 16:33 |
miker |
:) |
| 16:33 |
|
hbrennan joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:17 |
|
derekz left #evergreen |
| 17:54 |
|
abowling1 joined #evergreen |
| 18:15 |
|
abowling joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:30 |
|
finnx joined #evergreen |
| 20:31 |
|
Guest11856 left #evergreen |
| 20:36 |
|
jvwoolf joined #evergreen |
