| Time |
Nick |
Message |
| 00:02 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:41 |
|
bdljohn joined #evergreen |
| 07:58 |
|
collum joined #evergreen |
| 08:13 |
|
bos20k joined #evergreen |
| 08:26 |
|
Dyrcona joined #evergreen |
| 08:35 |
Dyrcona |
I guess 321 lineitems is too much to process normally on a purchase order. I had to go back and manually fire the event from srfsh. |
| 08:38 |
* Dyrcona |
considers adding a widget to let someone else do this from the staff client. |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 09:17 |
|
tlittle joined #evergreen |
| 09:19 |
bos20k |
Hello. Does anyone know what could cause a 'Context Loader error' from sub run_context_loader in OpenILS/WWW/EGWeb.pm? It is triggered when trying to view a record in the OPAC. The search returns results but then when we click on one of them we get internal server error in the browser and Contex Loader errors. |
| 09:21 |
Dyrcona |
bos20k: Do you have the line number from EGWeb.pm that triggers the error? |
| 09:21 |
bos20k |
172 in EG 3.1.8 |
| 09:23 |
bos20k |
The errors also mention line 1149 in OpenSRF/AppSession.pm |
| 09:24 |
bos20k |
Which is sub gather in AppSession |
| 09:24 |
Dyrcona |
Could be that OILSWebContextLoader is not defined/missing in the Apache2 config for the location/directory. |
| 09:25 |
bos20k |
We have PerlSetVar OILSWebContextLoader "OpenILS::WWW::EGCatLoader" and PerlSetVar OILSWebContextLoader "OpenILS::WWW::EGKPacLoader" in eg_vhost.conf |
| 09:26 |
Dyrcona |
Yeah. That's correct. Is this happening only with the OPAC or with KPAC, too? Also is it happening in the staff client? |
| 09:26 |
bos20k |
Other records work fine. There is something it doesn't like about two bib records for the same item (different pub dates). |
| 09:27 |
Dyrcona |
Um, you have 1 copy on two bib records? I don't think I understand your use of "the same item." |
| 09:27 |
bos20k |
It seems like it works in XUL. |
| 09:27 |
Dyrcona |
Well, I meant the web staff client. XUL is dead. :) |
| 09:28 |
bos20k |
Same 'book' different publisher dates. 2 copies on one bib record 12 on the other. |
| 09:29 |
Dyrcona |
Well, I'm lost because that should have nothing to do with a failure to load the context. The context should be loaded before you get to retrieving bib information. |
| 09:30 |
Dyrcona |
What's the error message after "Context Loader error:?" |
| 09:30 |
bos20k |
[Thu Feb 21 16:19:20.771809 2019] [perl:error] [pid 16386] [client 10.1.99.170:61290] egweb: Context Loader error: Exception: OpenSRF::EX::ERROR 2019-02-21T16:19:20 OpenILS::WWW::EGWeb /usr/local/share/perl/5.22.1/OpenILS/WWW/EGWeb.pm:172 System ERROR: Exception: OpenSRF::DomainObject::oilsMethodException 2019-02-21T16:19:20 OpenSRF::AppRequest /usr/local/share/perl/5.22.1/OpenSRF/AppSession.pm:1149 <500> Severe query |
| 09:30 |
bos20k |
error -- see error log for more details\n\n, referer: https://acorn.biblio.org/eg/staff/cat/catalog/record/1369065 |
| 09:31 |
Dyrcona |
Check the postgres logs for a query error, if you're logging them, but I usually don't find them. |
| 09:34 |
bos20k |
Hmmm, looks like it might be a problem in the MARC data. I was looking for problems in the MARC data and found a couple little things but they didn't make a difference. But this: |
| 09:34 |
bos20k |
2019-03-19 09:02:20.994 EDT [176854] evergreen eg_dbservices DETAIL: line 32: invalid character in attribute value |
| 09:34 |
bos20k |
1524720" lib="ANSONA" opac_visible="true" deleted="false" label="34045059435490t |
| 09:34 |
bos20k |
^ |
| 09:34 |
bos20k |
might lead me somewhere (carat is under the t at the end of the label). |
| 09:36 |
bos20k |
Line above that says "ERROR: invalid XML content". |
| 09:36 |
bos20k |
Dyrcona: Thanks for walking through that with me. I should have thought to check the PostgreSQL logs sooner... |
| 09:37 |
Dyrcona |
You're welcome. I was about to point out that it looks like something in the load_record subroutine of OpenILS/WWW/EGCatLoader/Record.pm blew up, but I think you've found the query. |
| 09:39 |
Dyrcona |
A lot goes on in that method. |
| 09:40 |
Dyrcona |
bos20k: Good luck! |
| 09:40 |
bos20k |
Thanks :) |
| 09:40 |
bos20k |
Dyrcona++ |
| 09:51 |
bos20k |
Looks like it's actually a bad label on a call number it contains '34045059435490t\x0C' weird. That call number has a create date in 2004 and an edit date in 2010. Either the Context Loader is more sensitive to bad data now or no one has looked at these books in a long time... |
| 09:52 |
|
yboston joined #evergreen |
| 09:53 |
|
sandbergja joined #evergreen |
| 09:53 |
Dyrcona |
Nifty! Some inserted a form feed into the label. |
| 10:04 |
|
nfBurton joined #evergreen |
| 10:13 |
|
Christineb joined #evergreen |
| 10:52 |
csharp |
@band add Memory Leak |
| 10:52 |
pinesol |
csharp: Band 'Memory Leak' added to list |
| 11:00 |
miker |
csharp: I wasn't around for your afternoon work, but I'd suggest 1) use round robin instead of weighted for LB 2) put the queue back 3) enable cross-domain router registration so the backend-driven API load is spread out, in addition to the client-driven load |
| 11:02 |
Dyrcona |
Yeah, I was going to mention that we're using round robin, and not weighted rr, either. |
| 11:02 |
* Dyrcona |
suspects memory leaks could also be an issue, particularly in mod_perl. |
| 11:03 |
miker |
with least-connected load balancing there can be a perverse inversion of load because not all "connections" are the same. because we mix "user-level" and "machine driven" sessions long running connections (user-driven) are mostly quiescent for their lifetime where as short-lived connections use more resources as a function of the length of their lifetime -- they're mostly /not/ quiescent. hope that makes sense... |
| 11:04 |
miker |
(there sould be a comma after "machine driven" sessions...) |
| 11:04 |
miker |
or a period. some punct... |
| 11:04 |
Dyrcona |
Or, I understood it anyway.... It's IRC... :) |
| 11:05 |
csharp |
miker: thanks for the suggestions! |
| 11:05 |
berick |
+1 to round-robin |
| 11:06 |
|
nfBurton joined #evergreen |
| 11:06 |
* Dyrcona |
is the typo king. |
| 11:06 |
miker |
anyway, we do those, and don't see "brick-ish" spikes -- it would indicate a problem is we /did/ see them, because there are multiple spreading mechanisms at various layers |
| 11:06 |
Dyrcona |
rr++ |
| 11:07 |
Dyrcona |
We see brickish spikes but nothing debilitating and the SIP connection counts that someone sends me every day about 6:00 pm are amusing. |
| 11:07 |
|
mmorgan joined #evergreen |
| 11:07 |
miker |
for instance, it would suggest we need to reregister services with routers because they aren't spreading load |
| 11:08 |
Dyrcona |
And, now that I think about it, the brickish spikes have been much less since I updated everything in 2017 to Ubuntu 16.04 and the new VM architecture. |
| 11:12 |
|
jamesrf joined #evergreen |
| 11:17 |
csharp |
would anyone be willing to share an example config for 1) single ejabberd shared across the cluster and/or 2) mulitple ejabberd where all the clients know about eachother? |
| 11:22 |
Dyrcona |
csharp: I don't have any handy, but 1 is relatively simple: Configure ejabberd to listen on domains with locally routeable addresses, i.e. 192.168.*, 10.*, 172.16.0.*.... Then configure your bricks to use those domains in opensrf_core.xml. |
| 11:23 |
Dyrcona |
csharp: Also with 1, you can use the same IP address for the public and private routers. They don't really care. |
| 11:24 |
Bmagic |
I am still having a heck of a time figuring out why my lost.auto triggers don't fire. MarkItemLost has a granularity, but the lost.auto triggers have the exact same granularity. Last night, MarkItemLost ran on 14 circs but zero lost.auto triggers fired. I think I found the log from open-ils.trigger.event.autocreate |
| 11:24 |
Dyrcona |
Bmagic: I don't think our lost.auto triggers have a granularity. I'll check again. |
| 11:25 |
Bmagic |
Right, but mine do and they worked fine before we upgraded to 3.1.10 |
| 11:25 |
Bmagic |
Mine need a granularity so I can pass a different action_trigger_filters.json file on cron |
| 11:26 |
Dyrcona |
Ok. I take that back. Of the two that are active, one has a custom granularity that works out to daily, the other doesn't. |
| 11:27 |
Dyrcona |
Ours are working, but we're on 3.0.13. |
| 11:28 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "Trigger logs" (7 lines) at http://paste.evergreen-ils.org/10507 |
| 11:28 |
Dyrcona |
They seem to be working on our 3.2 test machine. |
| 11:29 |
Dyrcona |
To answer your question, no. If that's the main trigger that marks items lost it goes by checkout.due. |
| 11:30 |
Dyrcona |
The notices and extra triggers that play off something going lost should have lost.auto. |
| 11:30 |
Bmagic |
yep, that's what I've got |
| 11:30 |
Bmagic |
I am trying to find the log that shows when it's searching for the definitions lost.auto |
| 11:31 |
mmorgan |
Bmagic: Is your action_trigger_filters.json file the same as before upgrade? |
| 11:31 |
Bmagic |
yes |
| 11:31 |
|
sandbergja joined #evergreen |
| 11:32 |
Dyrcona |
Bmagic: Do you have any action trigger runners running with --process-hooks, that do NOT also have --granulatiry-only? |
| 11:32 |
Dyrcona |
And, yeah, could be filters as mmorgan asked. |
| 11:33 |
Bmagic |
Dyrcona: yes: 0 12 * * * . /etc/profile && $EG_BIN_DIR/action_trigger_runner.pl --osrf-config $SRF_CORE --process-hooks --run-pending |
| 11:34 |
Dyrcona |
Only runs 1/day at noon? Maybe you should run it more often? |
| 11:35 |
Bmagic |
yeah, that might help but the ate currently has zero rows for the lost.auto definitions |
| 11:35 |
Bmagic |
pending or otherwise |
| 11:36 |
Bmagic |
do the lost.auto definitions need event_params "editor = 1" ? |
| 11:36 |
Dyrcona |
Well, I'm not the ate expert. |
| 11:37 |
Bmagic |
I'm considering converting the two lost.auto defs into standard checkout.due defs and have them fire before the MarkItemLost def |
| 11:37 |
mmorgan |
The lost.auto defs shouldn't need the editor event_params |
| 11:38 |
* Dyrcona |
has to sign out for a bit. Making a lunch run for someone else. |
| 11:38 |
Bmagic |
later |
| 11:38 |
mmorgan |
Bmagic: That's what we do, use the checkout.due hook for the notices as well as the mark lost (in our case mark long overdue) |
| 11:39 |
Bmagic |
So you don't rely on the "auto" mechanizm? |
| 11:39 |
Bmagic |
how do you prevent it from getting marked longoverdue first? |
| 11:39 |
Bmagic |
or do you have the validator set to NOOP_TRUE? |
| 11:39 |
mmorgan |
We don't but not for any good reason that I can remember. |
| 11:41 |
Bmagic |
stop_fines becomes the problem since action_trigger.json says "MAXFINES" or NULL - it will not react to circs that have been marked "LONGOVERDUE" unless you pass the special action_trigger_filter.json |
| 11:41 |
* mmorgan |
looks |
| 11:47 |
gsams |
Trying to implement auto-renewal properly, the notices are erroring out, can't use an undefined value as an array AppUtils.pm line 1315. |
| 11:47 |
mmorgan |
Bmagic: We use a custom filter that looks for LONGOVERDUE |
| 11:47 |
Bmagic |
I see |
| 11:47 |
Bmagic |
It's been a week without it working. Making tweaks everyday and see what happens the next day. Might be time to abandon lost.auto |
| 11:48 |
Bmagic |
If I do that though, items that are marked lost manually, won't fire the email |
| 11:52 |
|
khuckins joined #evergreen |
| 11:53 |
Bmagic |
wait a minute. I might have just noticed something |
| 11:54 |
Bmagic |
it looks like all of the marklost last night (though they are "complete") - had "MarkItemLost failed with event COPY_MARKED_LOST" |
| 11:55 |
mmorgan |
So nothing marked LOST to create the lost.auto event... |
| 11:55 |
mmorgan |
? |
| 11:55 |
Bmagic |
Can I assume that if the trigger doesn't make it all th way to marking the item lost, it won't fire the lost.auto stuff? |
| 11:56 |
Bmagic |
I think that's it! AssetCommon.pm will now assume it's marked lost if it's longoverdue |
| 11:57 |
Bmagic |
if ($copy->status == $args{status} || $copy->status == $args{alt_status}); |
| 11:57 |
Bmagic |
sheesh |
| 11:57 |
Bmagic |
I remember this now! LOL, two years ago I went through this same trial and I ended up editing that code. LOL. Documenting this now |
| 12:00 |
mmorgan |
Ah. Didn't realize your items were already LONGOVERDUE. |
| 12:01 |
Bmagic |
yeah, this is the situation from bug 1331174 |
| 12:01 |
pinesol |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 12:01 |
mmorgan |
Ok, gotcha. Related: bug 1562061 |
| 12:01 |
pinesol |
Launchpad bug 1562061 in Evergreen 3.1 "Marking a Long Overdue transaction Lost adds a second bill to the patron record" [Medium,Confirmed] https://launchpad.net/bugs/1562061 |
| 12:05 |
Bmagic |
I see what it is. ($copy->status == $args{alt_status} && !$ous_lod_to_lost) needs to be ($copy->status == $args{alt_status} && $ous_lod_to_lost) (removing the !) |
| 12:05 |
Bmagic |
or maybe it's a parenthesis issue |
| 12:05 |
Bmagic |
parentheses |
| 12:06 |
|
yboston joined #evergreen |
| 12:06 |
|
aabbee joined #evergreen |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:27 |
|
Dyrcona joined #evergreen |
| 12:27 |
Stompro |
Dyrcona, any chance you want to include the web based self check in the stripe V3 upgrade? It currently doesn't support Stripe at all. |
| 12:27 |
jeff |
I would not recommend that. |
| 12:28 |
Dyrcona |
Why not, jeff? |
| 12:28 |
jeff |
But I don't recommend allowing payments in web based self check to begin with, so... |
| 12:28 |
Dyrcona |
:) |
| 12:29 |
Dyrcona |
I'm not planning on including the web-based self check. My goal is to move to the Stripe Elements form for OPAC payments and remove CC pay from the web staff client, at least if Stripe is the processor. |
| 12:30 |
Stompro |
Ok, I just wanted to mention it. |
| 12:31 |
bos20k |
Question regarding what csharp was asking about ejabberd. Is there an advantage to having all bricks talk to one ejabberd? Right now each of our bricks has its own ejabberd and I'm not even sure if they 'know' about eachother. I must admit that when it seems ejabberd is working, I ignore it. |
| 12:33 |
Dyrcona |
Stompro: You could always open a Lp bug asking to have the web self-check support payments. That might elicit more details from jeff. :) |
| 12:33 |
nfBurton |
@Dyrcona What do you plan to use instead for payments? |
| 12:33 |
pinesol |
nfBurton: Can't locate Snark.pm in @INC |
| 12:33 |
Dyrcona |
bos20k: The advantage is that all of the bricks share the same pool of drones and listeners, so the load *can* get spread out more. Doesn't mean that it always will. |
| 12:34 |
Dyrcona |
nfBurton: The OPAC already accepts CC payments. I'm modifying that form to use Stripe Elements (aka V3) when Stripe is the processor. The web-based self check is an apparently little-known feature of Evergreen that allows patrons to check items out for themselves. |
| 12:34 |
Stompro |
Dyrcona, I think there is already a ticket. The web based self check does support Payflow pro... any maybe another. It just never had stripe support added. But it also has a nice bug where it will queue up multiple payments and charge customers multiple times. Maybe no-one uses it anymore? |
| 12:36 |
Dyrcona |
Ah. I see. We have a few sites that use the self check, and I'm pretty sure that they don't accept payments that way. |
| 12:36 |
nfBurton |
Ah, I see. I am looking at implementing an external paypal payment method in the future. |
| 12:37 |
Dyrcona |
Stripe Elements is essentially external. Everything important happens on Stripe's servers. |
| 12:38 |
Dyrcona |
It should not be too difficult to implement, either, but I have something personal going on next week, so might not get to it until after then. |
| 12:38 |
|
yboston joined #evergreen |
| 12:38 |
nfBurton |
I know.... My management doesn't like that it seems like we save the CC data so it is the only way they want to accept online payments. They fear negative perception from patrons |
| 12:39 |
Dyrcona |
Well, we don't save the CC data, at least, never more than the last 4 digits. |
| 12:40 |
Dyrcona |
And, I think the last 4 digits saving ended some time ago. |
| 12:40 |
Dyrcona |
The big deal for us with the way things are currently done is PCI compliance. |
| 12:41 |
Dyrcona |
With Elements, we supposedly won't have to worry about it. |
| 13:05 |
Dyrcona |
Following up on Lp 1820381, which will probably get turned into a question at some point, reminds me of this morning's discussion about ejabberd and using 1 ejabberd host for all of your bricks. |
| 13:05 |
pinesol |
Launchpad bug 1820381 in Evergreen "Staff login, Admin menu shows but. Login windows reamain" [Undecided,New] https://launchpad.net/bugs/1820381 |
| 13:06 |
Dyrcona |
In that case, you don't want the private.localhost and public.localhost domains, but if you're running a brick setup with drones running on different servers from the routers, you probably know that already. |
| 13:08 |
Dyrcona |
What you'd want is something like "192.168.0.223 router router.public router.private" in all of the /etc/hosts files, and then you use router.public router.private for the router names in opensrf_core.xml. |
| 13:09 |
Dyrcona |
This means that you have to firewall your Evergreen subnet from any other subnets because your private routers are hanging out unprotected on the LAN, but if you have decent rules, then they should be invisible to the Internet at large. |
| 13:09 |
Dyrcona |
Whatever you do, DO NOT use an internet-routable address for your private router and you probably don't want that for your public one, either. |
| 13:11 |
Dyrcona |
To do multiple ejabberds talking to each other, I think you just have to do something like the above, but for each host that runs ejabberd, and then list all of the host names in ejabberd.{yml,cfg}, but it has been a while sine I last looked at the config for that method, so I could be wildly off base. |
| 13:12 |
Dyrcona |
"I'm talkin' to myself in a @monologue." |
| 13:13 |
Dyrcona |
@monologue |
| 13:13 |
pinesol |
Dyrcona: Your current monologue is at least 12 lines long. |
| 13:13 |
bos20k |
I'm listening. :) |
| 13:13 |
Dyrcona |
:) |
| 13:14 |
bos20k |
I'm not sure if there would be enough benefit to doing any of these things? Is there a big disadvantage to isotated ejabberds? |
| 13:14 |
bos20k |
I know you said load balancing with the one ejabberd for all. But then I see the tradeoff that if that one ejabberd is down, so is all of our Evergreen system. |
| 13:15 |
Dyrcona |
No real disadvantage. It can help if you have a limited number of servers. At MVLC, we did something novel by splitting staff from public with different domains. We even made it so that XUL would not run on the public side. |
| 13:16 |
Dyrcona |
We also had a utility server on the staff side to run cron jobs, etc. We had it talk to the staff ejabberd and vice versa so the two could "share" drones. |
| 13:17 |
Dyrcona |
Well, yeah, that's the trouble with single points of failure. But it's similar to the effect of postgres being down, though potentially less dangerous. |
| 13:18 |
Dyrcona |
Having multiple ejabberds talking to each other is probably better. |
| 13:18 |
bos20k |
True. I guess one could do a warm standby or something with the one ejabberd. Switching from active to standby would be a process but if the ejabberd host exploded it would be quicker than starting from scratch. Sorta like a PostgreSQL replica but no replication going on. |
| 13:18 |
Dyrcona |
I think we're suggesting it to csharp because of patterns that he's seeing in his particular case: Some bricks are getting maxed out on some drones and others are sitting idle. |
| 13:19 |
Dyrcona |
In that case, it may help if going to round robin on the load balancer doesn't help. |
| 13:20 |
Dyrcona |
TBH, it has been a long time since I've seen ejabberd explode. erlang programs are not supposed to do that. :) |
| 13:20 |
bos20k |
I saw that discussion on round robin and made the change on our load balancers. Normally we see things relatively balanced but sometimes one sees way more load than the other. |
| 13:25 |
bos20k |
I think I remeber reading something about clustering with ejabberd? Assuming that exists and works in general, does it work with Evergreen? Would there be any benefits (such as fault tollerance)? |
| 13:26 |
Dyrcona |
I believe clustering does work with Evergreen, though I don't know if anyone has actually done it. That may be what tsbere set up at MVLC. I don't remember the exact details. |
| 13:26 |
miker |
bos20k: it does work. we used it for a long time |
| 13:27 |
miker |
but have moved away to simplify setup. we just use /tons/ of xmpp domains :) |
| 13:27 |
bos20k |
miker: Does it provide fault tollerance? Any other benefits (or downsides)? |
| 13:34 |
miker |
bos20k: main benefit for our use case was central auth configuration (we don't use the stock "router" and "opensrf" users). we still do that, but in a different way with separate domains, which opensrf routers make fault tolerant (cross-router registration) |
| 14:02 |
|
dkyle1 joined #evergreen |
| 14:03 |
* csharp |
notes that there is a high number of idle DB connections from across the bricks - does pcrud/cstore re-use those efficiently, or should we consider lowering the number of procs? |
| 14:03 |
csharp |
(procs = max_children) |
| 14:03 |
csharp |
cstore currently set to 128 and pcrud to 72 on each brick |
| 14:04 |
csharp |
DB has a 1000 connection limit, which we've only hit when the system is under duress |
| 14:04 |
csharp |
e.g., misconfigured |
| 14:04 |
gsams |
I'm getting an odd error with auto-renewal notifications, "undef error - Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.20.2/OpenILS/Application/AppUtils.pm line 1315." |
| 14:05 |
csharp |
seeing around 600 - 650 idle connections in pg_stat_activity |
| 14:09 |
gsams |
auto-renewals are working just fine, but I'm not really sure what part of the action trigger might be causing that error. It's the original trigger copied over and relatively unchanged. |
| 14:09 |
csharp |
gsams: looking at that line of that file, I would make sure the settings being called by the template actually exist |
| 14:10 |
csharp |
or that they have a value |
| 14:10 |
csharp |
(not sure, just noticing that the line reference (in 3.2, anyway) is within the ou_ancestor_setting subroutine |
| 14:11 |
berick |
or check for sql error around the same time |
| 14:12 |
berick |
json_query only returns undef if there was an error somewhere. |
| 14:14 |
gsams |
invalid input syntax for integer |
| 14:15 |
csharp |
so a problem with the template? or a setting that expected a number but someone entered text or an empty string |
| 14:16 |
csharp |
the all-of-a-sudden-ness of it with no changes on your end probably means a library entered a bad setting somewhere |
| 14:16 |
gsams |
looks like it's expecting a number but there is nothing instead. I'm guessing it's the template, looks like it's the From line that it's looking at. |
| 14:17 |
csharp |
check the actor.org_unit_setting table for empty strings |
| 14:17 |
csharp |
(for the setting that's consulted) |
| 14:17 |
gsams |
It errored with this statement: SELECT * FROM actor.org_unit_ancestor_setting( 'org.bounced_emails', '' ) AS "actor.org_unit_ancestor_setting" ; |
| 14:18 |
csharp |
hmm - that second param is probably expecting an org id |
| 14:19 |
gsams |
That's what it looks like |
| 14:19 |
gsams |
org_id integer |
| 14:33 |
gsams |
Ah, apparently it was a difference in template, it was looking at "target.home_ou.id" |
| 14:34 |
gsams |
Must have been a bad copy from a different type of notification. |
| 14:35 |
gsams |
Of course, now I'm getting a different error, but at least that one was resolved. |
| 14:39 |
gsams |
Okay, can't call method "call_number" on an undefined value. Reactor.pm line 129 |
| 14:40 |
gsams |
I'm not pulling a call number, but that line is in the midst of a section that pull title and author |
| 14:41 |
|
dpearl joined #evergreen |
| 14:41 |
gsams |
nevermind, I fixed it. There was an extra unnecessary event environment setup... |
| 14:41 |
gsams |
csharp++ |
| 14:41 |
Dyrcona |
gsams: It's failing to retrieve the copy on line 119 |
| 14:41 |
gsams |
berick++ |
| 14:42 |
Dyrcona |
gsams++ :) |
| 14:42 |
gsams |
And we have a working notification |
| 14:42 |
mmorgan |
gsams++ |
| 14:44 |
dpearl |
Help please. Newly built EG, clicking on Administration/Server Administrions elicits a Not Found error: The requested URL /eg2/staff/admin/server/splash was not found on this server. What am I missing? |
| 14:45 |
berick |
dpearl: installed from a release tarball? |
| 14:45 |
Dyrcona |
Probably from git. |
| 14:45 |
dpearl |
berick: GIT |
| 14:46 |
csharp |
ok, after reverting all bricks to apache2-websockets, drones have returned to sane levels |
| 14:46 |
berick |
dpearl: 1) need to create the angular build and 2) modify apache configs if they are out no up to date with 3.2 |
| 14:46 |
Dyrcona |
dpearl: You probably missed the steps to build eg2 from the README. I'm just about to sign out for a bit, but I'll be back later and check the logs. |
| 14:46 |
berick |
csharp: sone of a gun |
| 14:46 |
berick |
er, yeah, sone |
| 14:46 |
dpearl |
Thanks all |
| 14:47 |
bos20k |
Hmmm, problems with websoketd? I was just thinking about starting to mess around with it. |
| 14:47 |
berick |
csharp: is that with least-connections or round-robin load balancing? |
| 14:48 |
csharp |
berick: least connections |
| 14:48 |
csharp |
the only thing I've changed is disabling/stopping websocketd-osrf, re-enabling/starting apache2-websockets, and reactivating the older nginx config |
| 14:49 |
csharp |
so OpenSRF 3.1.0/Evergreen 3.2.3/apache2-websockets |
| 14:49 |
csharp |
system load on the bricks has stabilized too |
| 14:50 |
berick |
csharp: to recap the problem, services being really busy on some bricks and drones of various services maxing out? |
| 14:51 |
|
littlet joined #evergreen |
| 14:51 |
csharp |
correct |
| 14:51 |
berick |
and was there a pattern on which service types were maxing out? |
| 14:52 |
csharp |
random maxxing out of pcrud & actor |
| 14:52 |
berick |
k |
| 14:52 |
csharp |
yeah the others seemed to be ok/normal |
| 14:52 |
berick |
hmm |
| 14:53 |
csharp |
under apache2-websockets, the only service that gets high drone counts that I've noticed is settings |
| 14:54 |
csharp |
berick: my view: http://evergreen-ils.org/~csharp/drones.png |
| 14:54 |
berick |
csharp: and at the time, as far as you know, users weren't seeing problems? |
| 14:55 |
csharp |
correct - I verified with the PINES staff that no one had contacted them with any complaints |
| 14:55 |
csharp |
we suspect if they were seeing problems they didn't report them because they were transient |
| 15:00 |
csharp |
gsams++ #glad you found the issue |
| 15:26 |
|
sandbergja_ joined #evergreen |
| 15:41 |
mmorgan |
Quick poll: Lost and Long Overdue items do not display under "Current Items Checked Out" to a patron logged into the opac. Does anyone see this as problematic? |
| 15:41 |
mmorgan |
bug 1463907 |
| 15:42 |
pinesol |
Launchpad bug 1463907 in Evergreen "OPAC My Account display, the patron's view of items out does not include Long Overdue items" [Undecided,Confirmed] https://launchpad.net/bugs/1463907 |
| 15:46 |
bshum |
Sounds like a nice wishlist development to me |
| 15:46 |
bshum |
That or you should poll users of long-overdue status |
| 15:46 |
bshum |
If they don't use it, it wouldn't be a problem for them |
| 15:46 |
bshum |
Lost seems bad though... |
| 15:47 |
|
sandbergja_ joined #evergreen |
| 15:48 |
mmorgan |
It looks to be a pretty easy fix - as long as no one has a problem that Lost and Long Overdue would show to a patron under checked out items. |
| 15:48 |
mmorgan |
I'm wondering if YAOUS would be needed. |
| 15:49 |
bshum |
Are you sure there isn't already a YAOUS for this? |
| 15:49 |
bshum |
I'm looking back at https://bugs.launchpad.net/evergreen/+bug/1526159 and https://bugs.launchpad.net/evergreen/+bug/1665115 |
| 15:49 |
csharp |
spoke too soon - looks like we're hitting the same issue with apache2-websockets - will look at round-robin next |
| 15:49 |
pinesol |
Launchpad bug 1526159 in Evergreen 2.10 "Web client: items out count in patron summary is inaccurate" [Medium,Fix released] |
| 15:49 |
pinesol |
Launchpad bug 1665115 in Evergreen 2.12 "Web Client: Items Out does not include Long Overdue items" [Medium,Fix released] |
| 15:49 |
bshum |
Though I guess those are just counts |
| 15:49 |
bshum |
Not the actual listed item? |
| 15:50 |
mmorgan |
There are YAOUS for the display of Lost Long Overdue, etc for the staff client, xul anyway. Maybe just work off of those. |
| 15:50 |
bshum |
The bugs I linked were for web client, presumably |
| 15:53 |
bshum |
But going back to your initial bug question, that report seems to be about the patron's perspective? |
| 15:53 |
csharp |
looking at pre-3.2 upgrade logs from 1/16 (still on EG 3.0/Opensrf 3.0) I'm seeing maxxed out pcrud and actor "no children available" |
| 15:54 |
csharp |
so this isn't a new issue |
| 15:54 |
csharp |
I wonder why we haven't been hearing about it |
| 15:54 |
mmorgan |
Yes, patron's perspective. Seems like what shows as items out to staff should also show as items out to the patron. So maybe I've anwered my own question. Use the existing ou settings for the staff client to decide what to show to the patron. |
| 15:54 |
csharp |
just manifesting differently with websocketd |
| 16:02 |
jeff |
csharp: "why we haven't been hearing about it"... didn't you say that the only signs the other day (yesterday?) were from the logs? no reports from front line staff? |
| 16:03 |
csharp |
yes, correct |
| 16:03 |
csharp |
logs and nagios yelling at us |
| 16:04 |
csharp |
(system load warnings) |
| 16:04 |
jeff |
did you have same on Jan 16? |
| 16:05 |
berick |
csharp: the plot thickens |
| 16:06 |
csharp |
we have had high system load, but I'd been attributing that to the spinning apache2-websockets procs (which may have masked the other issue) |
| 16:06 |
|
bdljohn joined #evergreen |
| 16:12 |
|
yboston joined #evergreen |
| 16:26 |
|
yboston joined #evergreen |
| 16:45 |
|
nfBurton joined #evergreen |
| 16:45 |
csharp |
okay - websocketd is back in place - no significant difference between now and before with apache2-websockets |
| 16:45 |
csharp |
also looks like restarting services staves off the issue for a while |
| 16:46 |
nfBurton |
Quick Q: Running an update on my test server and keep getting " duplicate key value violates unique constraint "upgrade_log_pkey"". Is there something wrong with my DB or the upgrade script? |
| 16:46 |
nfBurton |
The DB upgrades are not my friend today |
| 16:47 |
csharp |
nfBurton: sounds like you're trying to apply an upgrade you already have? |
| 16:47 |
nfBurton |
I'm not though... |
| 16:47 |
csharp |
you can see which ones you have applied before in config.upgrade_log |
| 16:48 |
nfBurton |
There isn't even a primary key for this one in the db |
| 16:48 |
csharp |
Indexes: |
| 16:48 |
csharp |
"upgrade_log_pkey" PRIMARY KEY, btree (version) |
| 16:49 |
csharp |
it's using the "version" column as the primary key |
| 16:49 |
nfBurton |
OK. Pretty sure I haven't done this upgrade yet but maybe I have? It's all such a blur lol |
| 16:50 |
bshum |
By default, even fresh installs will have a value in upgrade_log |
| 16:50 |
bshum |
So you'd really need to see what was in there, and compare it against the SQL db upgrade script you're trying to apply |
| 16:50 |
bshum |
And see if there are conflicts |
| 16:51 |
* bshum |
always hated the upgrade scripts |
| 16:51 |
csharp |
I nearly always have to comment out parts of upgrade scripts |
| 16:51 |
csharp |
nfBurton: in the script you're running, look for SELECT evergreen.upgrade_deps_block_check and the version numbers will be there |
| 16:52 |
nfBurton |
That's annoying |
| 16:52 |
nfBurton |
I've been commenting those out since they aren't Combo Breakers |
| 16:53 |
csharp |
it only happens if you apply upgrade scripts outside normal "version" upgrades |
| 16:53 |
csharp |
which I think all of us do from time to time |
| 16:54 |
nfBurton |
Yeah. This is just my test which I thought was in line with my production site but may have pushed some updates along at some point |
| 16:55 |
nfBurton |
Is there a generally accepted reinjest script for the whole catalog as well? While I am here |
| 16:55 |
nfBurton |
I should run that too |
| 16:56 |
csharp |
nfBurton: Open-ILS/src/support-scripts/pingest.pl is nice if you have a large database |
| 16:56 |
nfBurton |
Ok cool |
| 16:57 |
nfBurton |
csharp++ |
| 16:58 |
csharp |
nfBurton: if you're DB is smaller, set the config.internal_flag setting named "ingest.reingest.force_on_same_marc" to the value of "false", enabled = true and do "update biblio.record_entry set id = id where not deleted" (then set the flag back to what it was before) |
| 16:58 |
csharp |
sorry, I meant "true" |
| 16:59 |
nfBurton |
Also, one more thing. How do I push changes to Format Icons and Format Searches through MARC Coded Value Maps. I have done so many things to try to push the data but the only thing that half helps is editing and saving the MARC |
| 16:59 |
nfBurton |
Appreciated, i will save that |
| 16:59 |
csharp |
nfBurton: reingest will take care of it (which is why editing/saving works) |
| 17:00 |
nfBurton |
I have reinjested single records with no update |
| 17:00 |
nfBurton |
Hopefully doing the whole catalogue will help |
| 17:00 |
csharp |
I would guess that the config.internal_flag is set to "false" then |
| 17:01 |
nfBurton |
I just end up with a blank tag even after editing and saving the MARC. My support contractor even didn't know what was going on and knows it can 'take a few days' for it to show up |
| 17:01 |
nfBurton |
LOL |
| 17:01 |
csharp |
hmm |
| 17:01 |
nfBurton |
Yeah |
| 17:01 |
nfBurton |
I have set up 3 new collections and they all do the same thing |
| 17:01 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-03-19T16:57:59,497208919-0400 -0> |
| 17:01 |
nfBurton |
I feel like a CRON job must clean them up if it randomly happens |
| 17:03 |
csharp |
might need to look directly at the metabib data for the records where it's not changing |
| 17:04 |
csharp |
that's getting into territory I'm less familiar with day-to-day, but have had to troubleshoot before |
| 17:05 |
nfBurton |
haha okay |
| 17:05 |
nfBurton |
I have been poking around but don't know enough of the backend quite yet |
| 17:05 |
nfBurton |
Thanks though |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
csharp |
perhaps a motivated individual will finally compile all these things into the Great Booke of Evergreene |
| 17:06 |
nfBurton |
One day.... |
| 17:06 |
berick |
Ye Olde Great... |
| 17:08 |
csharp |
... and OpenSerf |
| 17:11 |
berick |
hah |
| 17:20 |
Bmagic |
What's the state of affairs with cloning reports in the web based staff client. Specifically reports that were crafted with xul? |
| 17:22 |
csharp |
generally works for us |
| 17:23 |
Bmagic |
just found bug 1796945 |
| 17:23 |
pinesol |
Launchpad bug 1796945 in Evergreen "Report templates cloned from those created on XUL client causing error or producing different results" [High,Confirmed] https://launchpad.net/bugs/1796945 |
| 17:23 |
berick |
you need +20 Conjuration and the Staff of Zombies |
| 17:24 |
|
Dyrcona joined #evergreen |
| 17:24 |
dbwells |
Bmagic: yeah, I am commenting on that bug right now. I think it needs more work. |
| 17:24 |
Bmagic |
oh cool! OK great |
| 17:24 |
Bmagic |
dbwells++ |
| 17:26 |
pinesol |
[evergreen|Kyle Huckins] lp1749502 Holds Pull List Print Order - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=30bed84> |
| 17:26 |
pinesol |
[evergreen|Kyle Huckins] lp1749502 Prefix patch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3cf003e> |
| 17:26 |
pinesol |
[evergreen|Jason Stephenson] LP 1749502: Add Call Number Prefix & Suffix to pull list print template. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=706b74f> |
| 17:26 |
pinesol |
[evergreen|Josh Stompro] LP1749502 - Holds Pull List Print Order - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=358124e> |
| 17:31 |
Dyrcona |
Meant to push that during bug squashing week, but I missed it. |
| 17:37 |
|
yboston joined #evergreen |
| 17:39 |
Bmagic |
csharp: have you had any tickets related to renaming ACQ PO's? |
| 17:40 |
Bmagic |
I understand you are using nginx and EG 3.2? I am seeing POST 400 error in the browser console when renaming a PO (Same issue we had with dealing with monograph parts where remote_ip settings were the solution) |
| 17:44 |
berick |
Bmagic: just tried on a 3.2 multi-brick server running nginx and had no issue changing PO name, fwiw |
| 17:50 |
Bmagic |
load balanced? |
| 17:50 |
berick |
Bmagic: yes. |
| 17:50 |
Bmagic |
hmmm, thanks, I'll look deeper |
| 18:15 |
csharp |
Bmagic: I haven't heard anything here - I can ask, but I would imagine it would have come to me already if there's an issue |
| 20:26 |
|
sandbergja_ joined #evergreen |
| 21:36 |
|
sandbergja_ joined #evergreen |
| 22:09 |
|
sandbergja_ joined #evergreen |
