| Time |
Nick |
Message |
| 00:12 |
|
sandbergja joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:38 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
csharp joined #evergreen |
| 08:13 |
|
Dyrcona joined #evergreen |
| 08:27 |
csharp |
dbs: either Terran (out today) or I can help with carousel setup - that was early November, so I'm a bit rusty, but we definitely have it running the way we want on a test server |
| 08:28 |
csharp |
we have an office open house this morning and I'm kind of here and there all day, but I'll check in to see if you have a question/issue I might be able to help save time on |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:50 |
|
mantis1 joined #evergreen |
| 08:50 |
Dyrcona |
Ah, well. I guess yesterday's test was a bust. The log settings filled the 30GB of space available in / on my test vm. |
| 08:52 |
Dyrcona |
Amazingly, it didn't crash. |
| 08:57 |
Dyrcona |
Same data as production, though, and from what I can tell, the same patron was causing a problem. |
| 08:58 |
JBoyer |
logs cranked up to debug I suppose? |
| 09:00 |
Dyrcona |
Yeah, to debug. I couldn't do anything with sylog.1 except rm it. No 'temp space on device' if I tried to compress it, etc. |
| 09:01 |
Dyrcona |
Well, actually, I truncated it to 0, rather than rm it. |
| 09:02 |
JBoyer |
I suppose if it's a single patron that causes the issue you could invalidate a bunch of the events and just reset the biggest groupings, maybe it will fail faster? (OR it won't fail at all because Heisenbugs) |
| 09:06 |
Dyrcona |
If I leave the problem patron's events in collected state and set the other collected events t pending, the others succeed. |
| 09:06 |
Dyrcona |
I was just trying to confirm on my test sever what I concluded in bug 1858471, though I started before I filed the bug. |
| 09:07 |
pinesol |
Launchpad bug 1858471 in Evergreen "Events with large amount of data can crash action_trigger_runner.pl" [Undecided,New] https://launchpad.net/bugs/1858471 |
| 09:09 |
Dyrcona |
Turns out that I didn't need the debug log level to see what the problem. |
| 09:09 |
JBoyer |
Ah, right. I see it in there now. (the 3037383 byte message line) |
| 09:12 |
Dyrcona |
Yeah, that's one example, one of the larger values for someone with 30 items out. |
| 09:12 |
Dyrcona |
I've seen patrons with more items out have smaller message sizes. I think it depends a lot on the actual records, but I haven't really looked at what part. |
| 09:15 |
JBoyer |
Heh, I suppose there's always Data.Dumper(target) if you want to cause storage issues on your db also. :) |
| 09:22 |
Dyrcona |
Heh. |
| 09:23 |
Dyrcona |
I could just set this 1 patron up to run and dump that data. It should only be about a 3MB file. I may try that after lunch. |
| 09:24 |
Dyrcona |
I've adjusted max_stanza_size to 4,000,000 in production. Going through the logs for the past week, I didn't see any large messages bigger than 3.2 million or so. |
| 09:24 |
Dyrcona |
I should check the events in production from last night. |
| 09:25 |
Dyrcona |
This also seems to have been the problem with our courtesy notices, as well. It's hard to prove, but I saw some large message log entries with time stamps after that granularity started and before the auto-renews start. |
| 09:28 |
Dyrcona |
Nothing stuck from last night. |
| 09:29 |
Dyrcona |
A large message of 2,808,935 bytes was sent at 4:32 am, so could be either process. Looks like the max_stanza_size is working. :) |
| 09:33 |
JBoyer |
Did every large message cause this kind of problem? I'm not sure when the chunking is done vs. when the size is logged. |
| 09:36 |
Dyrcona |
From what I can see in the logs, yes. Every "sending large message" was followed 5 seconds later with a "JabberDisconnect Exception." |
| 09:39 |
|
collum joined #evergreen |
| 09:39 |
JBoyer |
Ok. |
| 10:01 |
|
mantis1 joined #evergreen |
| 10:03 |
|
sandbergja joined #evergreen |
| 10:12 |
|
mantis1 joined #evergreen |
| 10:27 |
* berick |
invents a 'staffcatalog' LP tag |
| 10:31 |
dbs |
thanks csharp - always hard to tell if there's something wrong in our environment, missing docs, missing code, or all three :) |
| 10:32 |
|
mantis2 joined #evergreen |
| 11:16 |
mmorgan |
Could an upgrade from 3.2.8 to 3.3.5 disrupt printer settings in the web client? |
| 11:18 |
mmorgan |
We've had reports of lost margin settings for receipt printer and inability to print to same. |
| 11:26 |
csharp |
mmorgan: we're testing 3.4 and have an issue report concerning receipt printing not working correctly |
| 11:26 |
csharp |
"From ARL: Chrome; hold slip did not automatically print or give the option to print on some computers, even with Auto-Print modifier on check-in screen. For the ones that did, format did not reflect the 4 letters last name - 4 digits card format. ---> (Note that they probably didn't have their custom print templates installed on their testing workstations)" |
| 11:27 |
csharp |
the parenthetical part was probably from Terran explaining what she thinks caused part of the issue |
| 11:27 |
csharp |
two of our staff here confirmed the issue, but I haven't looked closely yet |
| 11:28 |
csharp |
she thinks bug 1858118 is possibly related, so we've applied that fix to the test server and haven't had a chance to test |
| 11:28 |
pinesol |
Launchpad bug 1858118 in Evergreen "AngJS Always Tries To Use Hatch For Printing" [Critical,Fix committed] https://launchpad.net/bugs/1858118 |
| 11:30 |
* dbs |
wonders if his is the first site on 3.4 in production |
| 11:31 |
dbs |
If printing via Hatch, berick's suggestion of applying printer settings to each kind of printer (not just Default and Label) resolved some problems for us |
| 11:32 |
mmorgan |
csharp: Thanks for the info. Looks like that bug shouldn't be an issue on 3.3.5, though. We had several reports of lost printer settings, once folks reset them it was ok. One library had to disable/enable hatch a few times to get settings to 'stick' |
| 11:32 |
mmorgan |
dbs: Thanks for diving in first! :) |
| 11:34 |
|
mantis2 left #evergreen |
| 11:44 |
|
khuckins joined #evergreen |
| 11:51 |
|
tlittle joined #evergreen |
| 11:52 |
|
jihpringle joined #evergreen |
| 11:54 |
|
jvwoolf joined #evergreen |
| 11:56 |
csharp |
dbs: we're upgrading to 3.4 over Jan 18-21 (MLK) |
| 11:58 |
Bmagic |
I'm looking to introduce a couple of new fields into the browse index, specifically for series. It seems that I need to create a new Virtual Index, then define my new metabib field definition and glue it to the new Virtual Index. I'm unsure because there is already a "non-virtual-index" for series browse |
| 11:59 |
Bmagic |
I assume I will need to hook the previously existing non-virtual index to the virtual index... and that's where I am |
| 12:00 |
Bmagic |
what makes a metabib field definition a "Virtual Index" ? is it when it's name is "abstract"? |
| 12:00 |
Bmagic |
(like ID 45 for the blob) |
| 12:09 |
mmorgan |
Bmagic: I believe it's just the existence of mappings in metabib_field_virtual_map that make the field definition virtual |
| 12:09 |
Bmagic |
hm, I guess the word "Abstract" is an interface thing. I don't see it in config.metabib_field. Perhaps if any row in config.metabib_field_virtual_map makes it "abstract" |
| 12:10 |
Bmagic |
mmorgan: jinx |
| 12:10 |
mmorgan |
Heh. |
| 12:18 |
Bmagic |
something tells me I don't need this new virtual index |
| 12:24 |
pinesol |
[evergreen|Galen Charlton] LP#1843599: AngularJS MARC editor once again sets bib source - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=83a5d21> |
| 12:33 |
|
collum joined #evergreen |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:23 |
dbs |
Added a pull request and 3.4.2 milestone to bug 1805860 |
| 15:23 |
pinesol |
Launchpad bug 1805860 in Evergreen "Long Patron Names Hide Top Portion of Patron Account Screens" [Undecided,Confirmed] https://launchpad.net/bugs/1805860 |
| 16:18 |
|
jihpringle joined #evergreen |
| 16:24 |
Bmagic |
Anyone else run into this: Searching with Z39.50 tool, wanting to search OCLC and local catalog by TCN. OCLC tends to prefix the numeric ID number with different sets of letters. If you just use the numbers, the search doesn't work for OCLC/local catalog and visa versa? |
| 16:31 |
gmcharlt |
wel, this is a fun one: bug 1858698 |
| 16:31 |
pinesol |
Launchpad bug 1858698 in Evergreen "pull list: difference between displayed and printed list" [Medium,New] https://launchpad.net/bugs/1858698 |
| 16:33 |
Bmagic |
bug 1353036 |
| 16:33 |
pinesol |
Launchpad bug 1353036 in Evergreen "Searching: OCLC Number with junk characters (2.5.2)" [Undecided,New] https://launchpad.net/bugs/1353036 |
| 16:34 |
Bmagic |
gmcharlt++ |
| 16:34 |
Bmagic |
nice report |
| 16:36 |
jeff |
fun indeed. |
| 16:40 |
* Dyrcona |
shrugs. |
| 16:42 |
jeff |
I think I retroactively found one of the causes of duplicate transits. Probably doesn't change the solution/fix much, though. |
| 16:42 |
JBoyer |
Someday I'll stop trying to write bug reports at the same time I'm trying to fix the actual problem but apparently today is not that day. |
| 16:42 |
|
mmorgan joined #evergreen |
| 16:43 |
dbs |
Bmagic: so is there an assumption that the Evergreen instance is using OCLC numbers as their TCN in that particular case? |
| 16:43 |
Bmagic |
In theory, if you had Evergreen configured to keep the 001 field from the source record during import |
| 16:43 |
dbs |
because there are definitely libraries that are not doing that |
| 16:44 |
jeff |
Given an age hold protected item belonging to the Red library, with many holds that are excluded by nature of age hold protection, checking the item in at the Blue library takes a few seconds (while many hold permit checks run). Staff may then re-scan the item. Now we have two in-flight checkin attempts. |
| 16:44 |
jeff |
(the fix now in place prevents multiple in-flight checkin attempts -- at least, from the same client) |
| 16:44 |
Bmagic |
dbs: right |
| 16:44 |
Bmagic |
dbs: but |
| 16:46 |
jeff |
As the second checkin attempt runs through its hold permit checks, the first checkin attempt finds a permitted hold, and eventually captures the item for that hold and creates a hold copy transit. In the meantime, the second checkin attempt is checking for permitted holds and finds none. |
| 16:46 |
jeff |
The second checkin attempt then creates a normal (non-hold) transit to send the item to the Red library. |
| 16:47 |
jeff |
Now we have a "normal" and a "hold" transit for the same item from the Blue library to the Red library. Pretty sure the new index prevents this even when their send times are several seconds apart. |
| 16:48 |
jeff |
Eventually, the item turns up and checkin is attempted, and the system finds the non-hold transit first, and starts doing hold permit checks... |
| 16:49 |
jeff |
Now, if it finds a permitted hold and tries to capture it, we run into the index that prevents a copy from being captured for two different outstanding holds, and checkin fails. |
| 16:50 |
jeff |
anyway, pretty sure the fix for ye old bug 1787274 prevents the conditions leading up to the described scenario. |
| 16:50 |
pinesol |
Launchpad bug 1787274 in Evergreen 3.1 "Web Client: Transits Don't Always Clear" [Critical,Fix released] https://launchpad.net/bugs/1787274 |
| 16:57 |
|
book` joined #evergreen |
| 16:58 |
Bmagic |
dbs: if Evergreen was preserving the 001 as-is and not overwriting it with it's own ID number - AND the record came from OCLC (for example) AND you searched Z39.50 with both local and OCLC.... you get it |
| 17:09 |
|
mmorgan left #evergreen |
| 17:41 |
Bmagic |
@later tell mmorgan: sure |
| 17:41 |
pinesol |
Bmagic: The operation succeeded. |
| 17:59 |
dbs |
Bmagic: Yes, I get it. If a library only copy catalogued from a single source ever, sure. Or maybe if every library used UUIDs for their 001 to (probably) avoid conflicts |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:00 |
dbs |
That said, if someone wants to search for an OCLC number, identifier|oclcnum: works really well if the 001 and 003 identify that it comes from OCLC, and then gets moved predictably into 035 as (OCoLC)######### |
| 18:02 |
dbs |
But that would require searching the regular catalogue separately from Z39.50. (I don't think OCLC puts (OCoLC)######## into their own 035) |
| 18:28 |
dbs |
Also found out today that either the Norton Safe Web or IBM Trusteer Rapport extensions for Chrome subtly break the web staff client (symptom: trying to open the Reports interfac results in an ACTOR_USR_NOT_FOUND error dialogue, and console shows that an http translator call gets truncated) |
| 18:30 |
* dbs |
guesses that it's Rapport, largely because it's IBM. heh. apparently they're getting banks to distribute it: https://www.ibm.com/support/knowledgecenter/en/SS7MJT_1908/ug/c_Where_to_Download_Rapport.html |
