Time |
Nick |
Message |
01:23 |
|
yar joined #evergreen |
01:38 |
|
sard_ joined #evergreen |
05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:03 |
|
yar joined #evergreen |
06:58 |
|
agoben joined #evergreen |
07:13 |
|
rjackson_isl joined #evergreen |
08:06 |
|
bos20k joined #evergreen |
08:36 |
|
abowling1 left #evergreen |
08:37 |
|
abowling joined #evergreen |
08:40 |
|
mmorgan joined #evergreen |
08:53 |
|
Dyrcona joined #evergreen |
09:16 |
|
yboston joined #evergreen |
09:46 |
Dyrcona |
JBoyer: Did you ever tell me how long your autorenew events take to process? Ours are still running after 6 hours from last night's daily run on training. |
10:07 |
Dyrcona |
rjackson_isl++ |
10:08 |
Dyrcona |
A private chat confirms that their times and ours are roughly comparable, given the numbers of transactions being processed. |
10:08 |
jeff |
Approximately how many transactions? |
10:09 |
berick |
yikes |
10:09 |
jeff |
or, what's the overall rate of transactions/time? |
10:09 |
Dyrcona |
We get about 3 hours 40 minutes for 11,000+ autorenewal events. |
10:09 |
berick |
Dyrcona: running A/T in parallel? |
10:10 |
Dyrcona |
My current run is banging away at about 32,000 transactions. |
10:10 |
Dyrcona |
Yes, parallel of 3. |
10:10 |
berick |
*nod* |
10:11 |
Dyrcona |
I had used 6 in the past, but we ran into problems with a custom event template, and I had dropped parallel settings, and 3 was where it was at (or where I set it) when I fixed the template. |
10:11 |
Dyrcona |
But, things are faster than before we started using the parallel setting. |
10:12 |
Dyrcona |
I think I'll bump it to 6 on the training server after this lot "finishes." |
10:12 |
Dyrcona |
I am getting some events stuck in reacting and collected for these events. |
10:14 |
Dyrcona |
So, it looks like only autorenew is having events get stuck, the autorenew notices event has them all complete, except for the ones that are still being processed today. |
10:49 |
|
stephengwills joined #evergreen |
10:50 |
stephengwills |
query - are hold notifications an action trigger? |
10:50 |
berick |
stephengwills: yep |
10:51 |
stephengwills |
tx |
11:01 |
|
khuckins joined #evergreen |
11:02 |
|
yboston joined #evergreen |
11:24 |
|
Christineb joined #evergreen |
11:25 |
pinesol |
[evergreen|Mike Risher] lp1770217 Items Out count shouldn't increment on renew - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ebc2639> |
11:28 |
|
aabbee joined #evergreen |
11:37 |
|
rjackson_isl_ joined #evergreen |
11:39 |
|
dbwells joined #evergreen |
11:54 |
|
rjackson_isl joined #evergreen |
12:13 |
|
jihpringle joined #evergreen |
12:28 |
Bmagic |
I'm sure we are not the first to have this issue. Anyone messed with making Evergreen automatically invent a tag to a MARC record during import? Like a 902 for example? |
12:30 |
jeff |
s/invent/insert/? |
12:31 |
Bmagic |
meaning the tag never existed in either record |
12:32 |
* berick |
adds the ApplyForPatent module |
12:33 |
Bmagic |
But it's created/introduced onto the Evergreen MARC record during overlay |
12:33 |
Bmagic |
berick: haha |
12:37 |
berick |
Bmagic: adding the 901 field is the only scenario I'm aware of where that happens. of course, that's baked into the ingest logic. |
12:37 |
Bmagic |
right, postgres trigger |
12:38 |
Dyrcona |
Bmagic: Add a feature to run hooks on import: create and overlay hooks. |
12:38 |
Bmagic |
ME has come up with a 902 "signature" tag where individuals can record work done to the record |
12:39 |
berick |
ah, like a work log |
12:39 |
berick |
but wouldn't that require human intervention to add the 902 data? |
12:39 |
Bmagic |
yeah, who, what, when |
12:39 |
Dyrcona |
I wouldn't record that in the record. |
12:40 |
Dyrcona |
You don't audit the bre table? |
12:41 |
berick |
specifically, the "what changed" data.. unless that's just something generic like "merge" |
12:41 |
Bmagic |
Dyrcona: yes - catalogers don't see that table though. Unless it can be displayed on the record somewhere |
12:41 |
Dyrcona |
There's an Lp bug for that. |
12:41 |
Bmagic |
"Improved", "merged", "Added ISBN", basically anything |
12:41 |
berick |
Bmagic: those value would require a human to enter them, though, right? |
12:42 |
berick |
*values |
12:42 |
jeff |
sounds like Bmagic is looking for a process to automatically add the new tag, which would then be updated by hand from that point forward. |
12:42 |
Bmagic |
yes, it's all human right now. The request is to make at least the vandelay component automate that tag |
12:42 |
Dyrcona |
Right, they do, and will continue to. I think Bmagic just wants a some standard 902 created if it doesn't exist. |
12:42 |
jeff |
but trying to avoid catalogers needing to add the tag in the first place? |
12:42 |
* jeff |
nods |
12:43 |
Dyrcona |
Like I said, add hooks to the import code, then you can program a hook to do whatever you want. |
12:43 |
Bmagic |
right, creating the tag would be a nice thing for them to get a "stub" |
12:44 |
berick |
beware MARC records are patron-visible |
12:44 |
Dyrcona |
That, or you could modify the database trigger. |
12:44 |
Bmagic |
Dyrcona: that sounds like a good place - are you thinking in perl? or postgres? |
12:44 |
Dyrcona |
And what berick said is one reason I wouldn't do this in the MARC itself. |
12:45 |
Dyrcona |
I was thinking to add the hook mechanism in the Perl, but you'd probably need some database support to configure it. |
12:45 |
Bmagic |
yeah, maybe I could convince them not to use the tag |
12:46 |
Dyrcona |
Another reason that I wouldn't do it in the MARC is it makes the records longer, and doesn't add anything "useful" to the bibliographic data. |
12:47 |
Dyrcona |
It's metadata, and should be recorded elsewhere. |
12:47 |
Dyrcona |
Just my opinion.... |
12:47 |
berick |
and in this case, meta-metadata |
12:48 |
jeff |
m2data |
12:48 |
Dyrcona |
The easiest thing would be to add to one of the database triggers to add a 902 if it is missing. A way to add hooks to run arbitrary code when records are created or overlayed would be more generally useful in the long run. |
12:49 |
jeff |
I'm always looking for ways to make the database slower. |
12:49 |
jeff |
;-) |
12:49 |
Dyrcona |
:) |
12:50 |
Dyrcona |
I figure the hooks would run in Perl before the record goes into the databse, but you could define pre and post hooks, or possibly even "during" hooks, but I forget sometimes that Perl isn't Lisp. :) |
12:51 |
Bmagic |
The specific use case I have might not be where it should* be recorded. But while considering this project, I figured catalogers far and wide would love a way to introduce a new field into every record imported. A static configurable field for the software to automatically apply. Like the 049 |
12:52 |
Bmagic |
But the specifics (field number(s), subfield(s)) would be up to them |
12:52 |
Dyrcona |
Yes, something like that would be useful. |
12:52 |
* Dyrcona |
looks at some related code. |
12:55 |
Dyrcona |
I was trying to see if my "memory" is correct about there being a way to strip fields during Vandelay import. |
12:57 |
Bmagic |
Dyrcona++ # "memory" lol |
12:58 |
Dyrcona |
If there is, I'm not finding it. Maybe it was a wishlist thing? |
12:59 |
Bmagic |
I do seem to recall something about the auditor tables being visible on the record page for staff |
12:59 |
* mmorgan |
's memory remembers the term "trash fields" |
12:59 |
Bmagic |
a sort of "git" style view of the MARC history |
13:00 |
Dyrcona |
Bmagic: There's a wishl ist bug to add a wiki-like edit history view for bib records. |
13:00 |
Bmagic |
THAT would be sweet |
13:00 |
jeff |
we've played with synthesizing a git repo from the audit tables. |
13:00 |
Bmagic |
jeff++ |
13:01 |
berick |
what mmorgan said.. we have 'trash fields' -- you don't see them in the UI unless some are configured. |
13:01 |
jeff |
not something quite immediately useful to staff, but a start for "hey, what's changing and... can we answer 'why'?" |
13:01 |
berick |
altough I think in the Angular version, you see a placeholder for them, even if none are configured |
13:01 |
jeff |
I think bug 1828279 is the recent one that is being referred to above. |
13:01 |
pinesol |
Launchpad bug 1828279 in Evergreen "Wikipedia-style edit log for catalog records" [Wishlist,New] https://launchpad.net/bugs/1828279 |
13:02 |
Bmagic |
afk |
13:02 |
jeff |
Though I'm not sure I think "Wikipedia-style" is what I'd want to describe it as or implement. |
13:02 |
Dyrcona |
Yeah, I just found the bug because I was searching the wrong terms. |
13:03 |
Dyrcona |
hem.. That was ambiguous... jeff beat me to sharing the bug number because I was searching wiki and history before I tried wikipedia... |
13:04 |
Dyrcona |
Anyway.... :) |
13:05 |
Dyrcona |
I think a feature to add fields to imported records, prior to overlay and/or creation in the bre table, i.e. while they're in the import queue, would be useful. |
13:50 |
Dyrcona |
So, back to that action trigger discussion from this morning: Looks like it finished at 12:56 pm. I have 10 events that are still in a "reacting" state. I'm going to have a look at those. |
13:55 |
|
cmalm joined #evergreen |
14:05 |
Dyrcona |
So, I dumped the action_trigger.event entries to a csv for all of the reacting autorenew events, and something stands out about the data. The events all share process ids and update_time values. |
14:05 |
Dyrcona |
There are often 2 process ids for each day run, but sometimes only 1. |
14:05 |
Dyrcona |
So, this looks like a trigger back end process dying. |
14:11 |
Dyrcona |
The last messages to/from one of the pids occurs about 17 seconds after the update time of the db rows. |
14:12 |
Dyrcona |
But nothing to indicate that it died unexpectedly. |
14:13 |
Dyrcona |
Oops. It was 17 minutes, not 17 seconds... |
14:13 |
Dyrcona |
I, uh, read the time incorrectly. |
14:25 |
Dyrcona |
Interesting, one of these had the notice message created with the new due date, etc. I'm going to check the circulation to see if was actually renewed. |
14:26 |
Dyrcona |
Yes, it was successfully renewed. I suppose that I should check the others. |
14:29 |
Dyrcona |
Some renewed and some didn't. |
14:31 |
|
mmorgan1 joined #evergreen |
14:35 |
|
mmorgan joined #evergreen |
14:36 |
|
mmorgan2 joined #evergreen |
14:37 |
Dyrcona |
"Curiouser and curiouser," said Alice. |
14:38 |
Dyrcona |
So, of the "reacting" autorenewals that weren't renewed, they had autorenew notice events created to that effect: max renewals, patron exceeds fines, etc. |
14:39 |
Dyrcona |
So, it looks like the events were completed, but the a/t drone shut down before updating the events to that effect. |
14:45 |
Dyrcona |
@blame systemd-resolved for something unrelated to Dyrcona's monologue. |
14:45 |
pinesol |
Dyrcona: systemd-resolved stole Dyrcona's ice cream! for something unrelated to Dyrcona's monologue. |
14:48 |
Dyrcona |
pinesol: You're bringing the weak sauce. |
14:48 |
pinesol |
Dyrcona: Have you tried taking it apart and putting it back together again? |
14:57 |
Dyrcona |
pinesol: Now, you're just being a smart Alec. :) |
14:57 |
pinesol |
Dyrcona: Fire BAD! Reading GOOD! |
15:08 |
Dyrcona |
I don't recall it being mentioned in the documentation that one should increase the numbers of some drones that are allowed to run when switching over the web client. |
15:08 |
* Dyrcona |
is increasing the open-ils.actor max child value yet again. |
15:15 |
berick |
Dyrcona: re: A/T, i've mentioned this before, but was not really able to diagnose it, so I haven't bugged it. we had to comment out the code which creates the 'lost.auto', fired from with MarkItemLost, because running a subsequent A/T inside of an existing A/T reactor caused intermittent backend failures. |
15:15 |
berick |
the auto-renew code does the same thing and calls A/T from within A/T |
15:16 |
berick |
it seems to reach a tipping point where things get jammed up. it was unpredictable. |
15:16 |
Dyrcona |
berick: Thanks. I'll check for similar behavior with lost.auto. |
15:17 |
berick |
not sure what I'm going to do when we start doign autorenewals.. more so since the volume will be /way/ higher |
15:17 |
berick |
than marking lost |
15:17 |
Dyrcona |
I think I saw I "noticed" reacting events before but ignored them because I was looking into something else. |
15:17 |
Dyrcona |
Yes, it looks like the volume is much higher from my tests. |
15:38 |
Dyrcona |
Well, that's a bummer. The reports of problems don't coincide with the times that the logs indicated the 'no children available' messages. |
15:42 |
Dyrcona |
Well, not always... |
17:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
17:26 |
khuckins |
berick: For the in transit/reshelve_on_checkin part from CAT-222: |
17:26 |
khuckins |
OpenILS/Application/Circ/Transit.pm -> __abort_transit |
17:26 |
khuckins |
If the copy status is "In Transit" and the transit's copy status is Available, Checked Out, In Process, On Holds Shelf, In Transit, Cataloging, On Reservation Shelf, or Reshelving, it is changed it Canceled Transit. Otherwise the copy status reverts to what it was before the transit. An additional field for this seems like it would be excessive unless we were to have an "additional_rules" string field, or possibly a map table, "copy statu |
17:26 |
khuckins |
s properties/ccsp" for example, though that could also be excessive. |
17:28 |
khuckins |
That was an early comment on our end, but after diving some more into the code and getting to understand that workflow better, reshelve_on_checkin was born |
17:29 |
khuckins |
It's specifically when an item is "checked in" while in transit |
17:31 |
khuckins |
The SIP bit was in the "available" subroutine in SIP/Item.pm - rather than checking the existing is_available field, it was originally checking if the status was specifically Available or Reshelving |
17:34 |
khuckins |
RE: Offline Circulation's Show Time Picker(CAT-224) - It appears that the time picker itself isn't actually based on an OU setting - this might be worth filing a launchpad bug for, as some libraries might not want to use up the space that the time picker uses up |
17:56 |
berick |
@ana Circulation Show Time Picker |
17:56 |
pinesol |
berick: Criminal otherwise cock it up |
17:56 |
berick |
alrighty |
17:56 |
berick |
@quote random |
17:56 |
pinesol |
berick: Quote #110: "< Dyrcona> My fingers appear to be on strike." (added by csharp at 10:34 AM, April 15, 2015) |
21:38 |
|
book` joined #evergreen |
21:48 |
|
yar joined #evergreen |
23:46 |
|
sandbergja joined #evergreen |