Time |
Nick |
Message |
00:06 |
|
jamesrf joined #evergreen |
04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:01 |
|
agoben joined #evergreen |
07:06 |
|
rjackson_isl joined #evergreen |
07:25 |
|
dbwells_ joined #evergreen |
07:29 |
|
bdljohn joined #evergreen |
08:24 |
|
bos20k joined #evergreen |
09:05 |
|
yboston joined #evergreen |
09:05 |
|
jvwoolf joined #evergreen |
09:06 |
|
mmorgan joined #evergreen |
09:06 |
|
aabbee joined #evergreen |
09:07 |
|
Dyrcona joined #evergreen |
09:28 |
|
stephengwills joined #evergreen |
10:15 |
|
berick joined #evergreen |
10:36 |
|
jamesrf joined #evergreen |
10:44 |
|
yboston joined #evergreen |
10:58 |
|
Dyrcona joined #evergreen |
11:13 |
|
JBoyer joined #evergreen |
11:22 |
|
RMiller joined #evergreen |
11:26 |
RMiller |
I am missing something in the MARC Batch import. The records are importing, but not the items. It's not showing import errors, just 0 items imported. |
11:28 |
jeff |
you may need to configure and select a holdings import profile. |
11:29 |
jeff |
telling Evergreen which MARC tag contains information about the copies you are attempting to import, and which subfield contains a barcode, circ modifier, price, etc. (some of those are optional) |
11:30 |
|
Christineb joined #evergreen |
11:30 |
RMiller |
Doesn't the Evergreen export default holdings import profile have that? The record is showing me the item barcodes and everything. |
11:32 |
RMiller |
I set the Vandelay defaults in Library settings too |
11:34 |
|
sandbergja joined #evergreen |
11:38 |
|
jihpringle joined #evergreen |
11:38 |
jeff |
If you attempt to import a batch of records and you do not select a suitable Holdings Import Profile before selecting Upload, I don't think you'll have any copies created when importing those records. |
11:43 |
RMiller |
The documentation says to set the Owning library as well as Circulating library, but I don't see where to do that: http://docs.evergreen-ils.org/3.2/_import_item_attributes_2.html |
11:48 |
|
beanjammin joined #evergreen |
11:49 |
RMiller |
Wait, never mind, the scrolling is just weird. All the required fields are set |
11:56 |
|
yboston joined #evergreen |
12:08 |
|
jvwoolf joined #evergreen |
13:02 |
|
yboston joined #evergreen |
14:23 |
|
bdljohn1 joined #evergreen |
14:52 |
Dyrcona |
We have a developers' meeting scheduled to start in less than 10 minutes. Agenda is here: https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2019-01-09 |
14:54 |
berick |
Dyrcona++ # was just wondering about that |
14:56 |
Dyrcona |
If we think we'll have enough participants, I'll be happy to run the meeting. |
14:56 |
|
RMiller joined #evergreen |
14:57 |
Dyrcona |
If not, we can bounce the Agenda to next month. |
14:58 |
JBoyer |
Better you than me, given how the last time I ran a meeting went. |
14:59 |
Dyrcona |
Well, do we have the meeting or not? |
15:00 |
JBoyer |
Hello folks? The 3 of us would make for a very short meeting, if not especially productive. |
15:00 |
JBoyer |
If there's not some interest soon I'd say we wait until next time. |
15:00 |
JBoyer |
I haven't heard anything about the action item I'm attached to. :( |
15:01 |
Dyrcona |
It's mostly the three of us on the agenda. We could just do info items and call it quits. :) |
15:01 |
JBoyer |
#info Everything was tabled until next meeting, much karma will be given after. |
15:01 |
Dyrcona |
heh. |
15:02 |
berick |
@beer |
15:02 |
pinesol |
berick: Try restarting apache. |
15:02 |
Dyrcona |
I say we wait ten minutes or so to give others a chance to show up. ;) |
15:02 |
Dyrcona |
@swill |
15:02 |
* pinesol |
grabs a forty of Jeremiah Weed and sends it sliding down the bar to Dyrcona |
15:02 |
JBoyer |
pinesol has betrayed us. Naught but @whisky and @swill? |
15:02 |
pinesol |
JBoyer: BIG LETTERS MEAN BIG IDEAS, AM I RIGHT THOUGHT LEADERS? |
15:02 |
Dyrcona |
@batender |
15:02 |
pinesol |
Dyrcona: Try restarting apache. |
15:02 |
JBoyer |
That is my favorite dunno. |
15:03 |
Dyrcona |
Yeah, BIG LETTERS is a good one. |
15:03 |
RMiller |
Um. Is anyone free to help me figure out why my records import but my items don't? |
15:04 |
* Dyrcona |
is not the expert in Vandelay. |
15:04 |
JBoyer |
Perhaps. Is there a place you can post a couple screenshots? The easiest way to see what might be happening is to see all of your selections on the batch import screen and maybe a couple lines of the text version of your holdings fields. |
15:05 |
RMiller |
Maybe. Let me work on that. |
15:06 |
Dyrcona |
Yeah, a mismatch between the profile(?) and the holdings fields in the records was my first thought when I saw your email, but like I said, I'm not really expert with that part of the system. |
15:07 |
Dyrcona |
Looks like we missed last January's meeting, too. |
15:08 |
Dyrcona |
May as well call it. I'll send an email and update the wiki. |
15:08 |
JBoyer |
Dyrcona++ |
15:10 |
berick |
Dyrcona++ |
15:16 |
RMiller |
Screenshots: https://drive.google.com/drive/folders/1ft09epKxHZkczrNrsV21G3EEiV9CVffJ?usp=sharing |
15:17 |
RMiller |
The XML was exported from 2.8, trying import straight into 3.2 |
15:20 |
JBoyer |
One thing that comes to mind is that since you didn't check Merge on Single Match it wouldn't do anything with matching records on import. (There are a lot of records in the queue screenshot with matches) |
15:21 |
RMiller |
They should all match- they're literally the only thing in the catalog so far |
15:22 |
JBoyer |
Meaning they were in your 3.2 database before the import? |
15:23 |
RMiller |
The first time I tried it, it imported the records and then had all the items fail because I hadn't set the circulation modifier :) |
15:24 |
JBoyer |
Ah. In that case you'll need to also check the Merge on Single Match box. (I'm not sure what Best Match does with a ratio of 0. "Quality" is so vague we don't use it locally for anything) That should allow it to try to import the items again. |
15:25 |
RMiller |
So Match-only merge for the merge profile, with Single Match checked? |
15:27 |
JBoyer |
Match Only is fine for this case where you already know they're the same record. You can also check multiple boxes; Single Match and Import Non-Matching go well together. (doesn't matter in this case, but I thought I'd mention it.) |
15:28 |
JBoyer |
if you pull up one of these records in the editor, do they still have your 852 in them? |
15:30 |
RMiller |
Yes, the 852 is still there |
15:31 |
JBoyer |
If they don't load as expected this time with the merge on single match box checked you might include a screenshot of one of the records showing the 852. Text mode would be the easiest to read. |
15:32 |
JBoyer |
That said, I hope the import will work because I need to head out for the day. Good luck RMiller! |
15:36 |
RMiller |
Thanks for trying :) |
15:38 |
RMiller |
MARC View for an imported record: https://drive.google.com/open?id=16ggMxA_ninJTO3Hv108_vbxlkPGp6Xvn |
15:38 |
RMiller |
...but empty Holdings view :( https://drive.google.com/open?id=1BygSnHM-pL-BNO12lUc2aRvWMjaanSv3 |
15:49 |
Bmagic_ |
Here's one I've not seen: XUL client login box with: "Service Unavailable: Back-end server is at capacity" - I can't find that error message in the source code. I wonder if that means that one of the bricks is 100% for auth? |
15:50 |
|
yboston joined #evergreen |
15:51 |
|
dpearl joined #evergreen |
15:52 |
berick |
Bmagic: i think that's an http thing, not an evergreen/opensrf thing |
15:52 |
Bmagic |
oh! thanks |
15:53 |
Bmagic |
berick++ |
15:53 |
berick |
i mean, it could be caused by EG, but the message is not coming from EG |
15:54 |
Bmagic |
I suppose Apache was at it's MaxRequestWorkers |
15:54 |
Bmagic |
Web client tends to gobble those up |
15:55 |
|
dpearl_ joined #evergreen |
15:55 |
|
dpearl left #evergreen |
16:00 |
jeffdavis |
We use the default MaxRequestWorkers here and I don't think we've run into issues with it (although we don't monitor # of Apache procs directly). We do see EG drone exhaustion sometimes with the web client, usually open-ils.pcrud. |
16:01 |
Bmagic |
jeffdavis: what's it set to? 150? |
16:01 |
jeffdavis |
mods-enabled/mpm_prefork.conf has 75 |
16:02 |
Bmagic |
ps aux|grep apache|wc shows each brick around 120 |
16:03 |
berick |
Bmagic: load look OK on those machines? that's a healthy number of apache clients |
16:03 |
Dyrcona |
Bmagic: Shortcut to the above: pgrep -fc apache2 |
16:04 |
Bmagic |
I'm sure during peak, they could easily get to 150. now that I am waching, I see one brick hit 150 |
16:04 |
Dyrcona |
MVLC had problems hitting max Apache2 processes a few years ago. I don't recall that we ever had a solution. |
16:04 |
berick |
Bmagic: which is fine, if the box has resources to handle it, of course |
16:05 |
Bmagic |
CPU on said machine went out of control, now it's cooling down |
16:05 |
Dyrcona |
You can probably find lots of discussion about the things that I tried if you search the IRC logs. |
16:05 |
Bmagic |
yeah, and I am sure I was one of the participating parties in the IRC discussions, lol |
16:05 |
Dyrcona |
You were. |
16:05 |
Bmagic |
:) |
16:05 |
Dyrcona |
So was berick and several others. |
16:06 |
Bmagic |
afk - office party, CAG's birthday |
16:06 |
jeffdavis |
pgrep shows about 15 apache processes on each of our 3 servers here fwiw |
16:07 |
Dyrcona |
Ours can vary widely, but I'm going to have a look. |
16:08 |
Dyrcona |
pgrep shows 47-60 on each of our brick heads. We have 5. |
16:11 |
jeffdavis |
ah, we're capping StartServers quite low |
16:12 |
jeffdavis |
matching what's in the INSTALL doc though |
16:12 |
bshum |
Well the install doc was written with only 4GB of RAM in mind, for all of Evergreen+PG+Apache2 |
16:13 |
jeffdavis |
yeah I should probably experiment with those settings |
16:13 |
bshum |
It used to be higher, but then we found that certain test servers were dying due to lack of RAM :) |
16:15 |
Dyrcona |
We apparently go with the default from mpm_prefork.conf |
16:17 |
|
remingtron joined #evergreen |
16:18 |
Dyrcona |
So, maybe Bmagic needs another "brick?" |
16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
16:48 |
|
remingtron joined #evergreen |
16:53 |
Bmagic |
Dyrcona: 6 bricks already. I think they are underutilized. 16GB memory, 4CPU, 8GB swap. I think they can go a bit higher on the apache workers. Like 200 |
16:57 |
berick |
Bmagic: how's the CPU load look on those? 120 active apache processes on 4CPUs seems like a lot |
16:57 |
Bmagic |
not bad really |
16:57 |
berick |
is it still around 120? |
16:57 |
Bmagic |
70% average over all 6 bricks |
16:58 |
Bmagic |
yeah, 120, 130 ish |
16:59 |
Dyrcona |
Well, I'll leave you to mull it over. I'm calling it a day and heading home. |
16:59 |
Bmagic |
lata! |
16:59 |
Bmagic |
There's not an issue currently, I was just curious how that error message would have occurred and I think we nailed it. Apache was out of connections |
17:00 |
* berick |
nods |
17:06 |
|
mmorgan left #evergreen |
17:21 |
Bmagic |
You can't delete pending patrons in the web client? |
17:23 |
berick |
bug 1737800 |
17:23 |
pinesol |
Launchpad bug 1737800 in Evergreen "Web Client: Pending Patrons No Delete" [Medium,Confirmed] https://launchpad.net/bugs/1737800 |
17:23 |
Bmagic |
ah! launchpad_search-- |
17:24 |
Bmagic |
user_error++ |
17:25 |
Bmagic |
launchpad_search++ |
17:26 |
berick |
@karma launchpad_search |
17:26 |
pinesol |
berick: Karma for "launchpad_search" has been increased 1 time and decreased 1 time for a total karma of 0. |
17:26 |
Bmagic |
haha |
17:26 |
Bmagic |
I was about to do the same thing |
17:27 |
Bmagic |
I thought someone else messed with that karma but it might have been reset since then |
17:27 |
Bmagic |
I thought the general consensus was negative for launchpad search |
17:55 |
gmcharlt |
the OpenSRF 3.1 beta is now available: https://evergreen-ils.org/opensrf-3-1-0-beta-released/ |
17:58 |
berick |
gmcharlt++ |
17:59 |
|
sandbergja_ joined #evergreen |
18:47 |
|
stephengwills joined #evergreen |
18:58 |
|
stephengwills joined #evergreen |
19:12 |
|
stephengwills joined #evergreen |
19:49 |
|
sandbergja joined #evergreen |
19:51 |
|
stephengwills joined #evergreen |
20:02 |
jeff |
Bmagic: you may have come to this realization already, but that specific error is likely being generated by your ELB. I'm guessing that that was one of your AWS installs? |
20:04 |
jeff |
Bmagic: do you know if it was a 503 or a 504? |
20:05 |
jeff |
Guessing 503. |
20:07 |
jeff |
You might look into what you're doing for health checks, and if those were failing. There's a CloudWatch metric that should show your count of healthy hosts for the time in question. |
20:34 |
Bmagic |
jeff: yep 503, yep ELB. Health checks are simple, looking for 200 on http. The bricks themselves have internal checks that remove themselves under more complex conditions. The error is occurring when apache hits the configured 150 limit which in-turn reports 503 to ELB (if im not mistaken) |
20:36 |
Bmagic |
if the ELB doesn't get it's configured response for the configured number of consecutive checks, then it's automatically removed from the pool and therefore, should not show it's face to the public. |
22:02 |
|
bwicksall_ joined #evergreen |
22:17 |
|
bwicksall joined #evergreen |
23:27 |
|
sandbergja joined #evergreen |
23:31 |
|
stephengwills joined #evergreen |