| Time |
Nick |
Message |
| 06:41 |
csharp |
@later tell linuxhiker what OS platform are you on? I would recommend Debian or Ubuntu if you have a choice in the matter |
| 06:41 |
pinesol_green |
csharp: The operation succeeded. |
| 07:39 |
|
rjackson-isl joined #evergreen |
| 07:45 |
|
jboyer-isl joined #evergreen |
| 07:54 |
csharp |
@blame IE11 |
| 07:54 |
pinesol_green |
csharp: Your failure is now complete, IE11. |
| 08:24 |
|
RoganH joined #evergreen |
| 08:30 |
|
akilsdonk joined #evergreen |
| 08:31 |
|
mrpeters joined #evergreen |
| 08:44 |
dbs |
csharp: I think linuxhiker = linuxpoet, therefore RHEL seems likely |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:47 |
|
kbeswick joined #evergreen |
| 08:54 |
dbs |
:/ |
| 08:55 |
|
ericar joined #evergreen |
| 09:05 |
|
Shae joined #evergreen |
| 09:07 |
|
timlaptop joined #evergreen |
| 09:08 |
|
collum joined #evergreen |
| 09:36 |
csharp |
so is anyone beside KCLS running RHEL/CentOS? |
| 09:39 |
tsbere |
I run CentOS on some of my personal servers. But not for Evergreen/OpenSRF in any capacity. >_> |
| 09:40 |
csharp |
yeah - just wondering |
| 09:42 |
jboyer-isl |
So, has anyone run into a situation like this with Slony-I? Replication has essentially stopped because an event appears to be repeating, so it constantly spews " ESTERROR remoteWorkerThread_1: "SO_MUCH_SQL"..."already exists". qualification was... etc. |
| 09:44 |
csharp |
jboyer-isl: have you made any schema changes? |
| 09:44 |
csharp |
slony errors are not very helpful *and* poorly documented ime ;-) |
| 09:45 |
csharp |
s/;-)/:-(/ |
| 09:45 |
jboyer-isl |
Nope. Just loaded our config.circ_matrix_matchpoint rules (that's what the SO MUCH SQL is, the ccmm inserts) |
| 09:45 |
|
ericar joined #evergreen |
| 09:45 |
csharp |
hmm |
| 09:46 |
jboyer-isl |
Unless past upgrades missed part of the upgrade scripts, but I would hope we'd have noticed that before now. |
| 09:46 |
csharp |
jboyer-isl: would you mind pastebinning the full error? I'm just curious to see it in context |
| 09:47 |
jboyer-isl |
sure, there isn't anything sensitive in it. I'll throw in a little context just in case. |
| 09:49 |
|
mllewellyn joined #evergreen |
| 09:50 |
pastebot |
"jboyer-isl" at 64.57.241.14 pasted "Slony hanging up on this insert" (79 lines) at http://paste.evergreen-ils.org/35 |
| 09:50 |
dbs |
csharp: IISH was trying to go RHEL/CentOS but I think they wound up with Debian in the end |
| 09:50 |
csharp |
dbs: interesting |
| 09:51 |
csharp |
ERROR: duplicate key value violates unique constraint "ccmm_once_per_paramset" |
| 09:51 |
csharp |
DETAIL: Key (org_unit, grp, (COALESCE(circ_modifier, ''::text)), (COALESCE(marc_type, ''::text)), (COALESCE(marc_form, ''::text)), (COALESCE(marc_bib_level, '': |
| 09:51 |
csharp |
:text)), (COALESCE(marc_vr_format, ''::text)), (COALESCE(copy_circ_lib::text, ''::text)), (COALESCE(copy_owning_lib::text, ''::text)), (COALESCE(user_home_ou::te |
| 09:51 |
csharp |
xt, ''::text)), (COALESCE(ref_flag::text, ''::text)), (COALESCE(juvenile_flag::text, ''::text)), (COALESCE(is_renewal::text, ''::text)), (COALESCE(usr_age_lower_ |
| 09:51 |
csharp |
bound::text, ''::text)), (COALESCE(usr_age_upper_bound::text, ''::text)), (COALESCE(item_age::text, ''::text)))=(1, 1, , , , , , , , , , , , , , ) already exists |
| 09:51 |
csharp |
bleh - sorry |
| 09:51 |
csharp |
jboyer-isl: that's the key error, I think |
| 09:52 |
dbs |
csharp: they were in contact with an EPEL-approved packager who was going to do package up all the dependencies, but that sadly never came to fruition. It got me on Fedora though |
| 09:52 |
jboyer-isl |
Yes. But how to get slony past is is my concern. I'm hesitant to delete anything out of _replication.* |
| 09:52 |
jeff |
for whatever reason, slony is trying to insert something that's already there. did you do something outside of what slony pays attention to? |
| 09:52 |
jboyer-isl |
Nope. Just ran a scripted insert on the master. |
| 09:52 |
jeff |
did you TRUNCATE before loading things in? my slony-fu is weak, but iirc that's something that can cause problems. |
| 09:52 |
csharp |
sounds like the replica/one of the replicas already had that row? |
| 09:53 |
mrpeters |
eeeek yeah there was truncates |
| 09:53 |
jboyer-isl |
jeff: Yes. That didn't occur to me at the time. |
| 09:53 |
mrpeters |
now that im seeing jboyer-isl script again |
| 09:54 |
mrpeters |
jboyer-isl: you'll prob need to take reports down and rebuild the replicas |
| 09:54 |
mrpeters |
we can assist |
| 09:55 |
jeff |
if the truncate was limited to a handful of tables, it might be possible to perform the truncate on the slaves to fix things. i do not know enough to be able to recommend that. |
| 09:55 |
mrpeters |
jeff: you might be right |
| 09:56 |
jboyer-isl |
It was only config.circ_matrix_matchpoint and it's related tables. I don't know if that will get it done or not. :/ |
| 09:57 |
jeff |
i found this which supports my theory, but is several years old: http://shoaibmir.wordpress.com/2010/06/03/truncate-problems-with-slony/ |
| 09:57 |
jeff |
there's also this slony bug which seems to indicate that some form of support for truncate was added to slony, but i didn't look closely to see what release, etc. also from 2010: http://www.slony.info/bugzilla/show_bug.cgi?id=134 |
| 09:57 |
pinesol_green |
www.slony.info bug 134 in stored procedures "TRUNCATE support" [Enhancement,Resolved: fixed] - Assigned to cbbrowne |
| 09:57 |
csharp |
at a cursory glance of google results, it looks like more recent slony versions may support TRUNCATE |
| 09:58 |
csharp |
pinesol_green++ |
| 09:58 |
jboyer-isl |
I'm going to try that out real quick on one of our rarely used slaves |
| 09:59 |
|
ldwhalen joined #evergreen |
| 10:00 |
jboyer-isl |
Ah, sweet relief. |
| 10:00 |
mrpeters |
it work? |
| 10:00 |
csharp |
jboyer-isl: nice! |
| 10:00 |
jboyer-isl |
Yeah, the syncs are flying by now. |
| 10:00 |
|
yboston joined #evergreen |
| 10:00 |
mrpeters |
what was the command? |
| 10:01 |
jboyer-isl |
Same as the script. truncate config.... cascade. |
| 10:01 |
jboyer-isl |
There's a single example row in that table that was blocking things. :/ |
| 10:02 |
mrpeters |
ah nice |
| 10:02 |
mrpeters |
glad that worked |
| 10:03 |
jboyer-isl |
me too, re-syncing all of them is not my idea of a good time. I guess it's "DELETE FROM X" until we're on PITR sycing. |
| 10:04 |
mrpeters |
there should be a document (PDF) at ISL that details how to avoid this |
| 10:04 |
mrpeters |
if you dont have it, i do, ill send it to you |
| 10:04 |
mrpeters |
would be on the wiki |
| 10:04 |
jboyer-isl |
Thanks for the help everyone, <picks up pipe> I think we all learned a valuable lesson today. <puts pipe down> |
| 10:05 |
csharp |
jboyer-isl++ |
| 10:05 |
jboyer-isl |
mrpeters: I've probably got it someplace. I already had to add a new schema/table to slony once. It just didn't occur to me that truncate is fine on mig but a showstopper on the rest. |
| 10:05 |
mrpeters |
right |
| 10:10 |
csharp |
uhoh - looks like a server went down? |
| 10:11 |
|
rfrasur joined #evergreen |
| 10:11 |
dbs |
:/ |
| 10:22 |
|
rfrasur_ joined #evergreen |
| 10:22 |
|
senator joined #evergreen |
| 10:31 |
|
hopkinsju joined #evergreen |
| 10:42 |
rfrasur |
jboyer-isl: is it correct behavior that until something overwrites a reconciliation report, the last one will continue to show up? |
| 10:43 |
jboyer-isl |
Yes, the latest one is always at the top. I have to re-run today's though (I was waiting for the databases to sync up). |
| 10:44 |
jboyer-isl |
And now they're current. |
| 10:44 |
rfrasur |
so, does it actually list up to 30? and then they drop off the screen (and into a black hole) or is only the most recent displayed? (obviously we don't deal with this much) |
| 10:45 |
jboyer-isl |
Yes, it has 2 at the top, and then 28 more in a table. reports older than the 30th displayed are deleted. |
| 10:46 |
|
senator joined #evergreen |
| 10:46 |
rfrasur |
awesome. I was fretting about the weekends. No need. |
| 10:46 |
jboyer-isl |
I'll also be running a "month of November total" report on Dec 1st, so libs can track their progress. That's a one-off though unless there are issues. |
| 10:46 |
rfrasur |
awesome. ty. |
| 11:02 |
|
gdunbar joined #evergreen |
| 11:06 |
|
phasefx2 joined #evergreen |
| 11:06 |
|
eeevil joined #evergreen |
| 11:18 |
|
smyers_ joined #evergreen |
| 11:25 |
* paxed |
ponders if he should bother filing wishlist bugs for the functionalities missing from evergreen that would be useful for finnish libraries. |
| 11:26 |
* csharp |
votes "yes" |
| 11:26 |
csharp |
:-D |
| 11:28 |
|
kmlussier joined #evergreen |
| 11:30 |
* rfrasur |
also votes "yes." |
| 11:30 |
rfrasur |
you never know when it's gonna pertain to someone else. |
| 11:30 |
jboyer-isl |
It never hurts to know what could be done to improve, even if they don't happen right away. |
| 11:32 |
|
RoganH joined #evergreen |
| 11:34 |
|
eeevil joined #evergreen |
| 11:34 |
jboyer-isl |
So I'm new to the in-db circ scene, is the renewals field used over the max_renewals field in the config.rule_circ_duration table? |
| 11:35 |
jboyer-isl |
Because as far as I could see with respect to holds, the age protection field isn't currently referenced. |
| 11:36 |
rfrasur |
I'm not sure the term for the db, but I know renewals are based off the circ modifier. |
| 11:37 |
jboyer-isl |
rfrausr: Well... not exactly. It's tied to the circ_duration rules, but we have some rules that are the same except one allows a renewal and one doesn't, things like that. |
| 11:38 |
jboyer-isl |
Those were applied to the various circ mods depending on if we wanted to allow a renewal or not. |
| 11:38 |
jboyer-isl |
But I think things have changed. |
| 11:38 |
mmorgan |
jboyer-isl: yes, config.circ_matrix_matchpoint.renewals lets you override the number of renewals set in the duration rule. |
| 11:39 |
rfrasur |
I hope they haven't changed too much since that's why we use certain circ mods. |
| 11:39 |
jboyer-isl |
Is it only override, so if renewals is set to null in all rules, all of the durations are used as usual? |
| 11:41 |
jboyer-isl |
Ugh. I see what happened. I switched the plain circ mod's rules and the "new" circ mod's rules. Now only the new items get a renewal! :D Easy enough to gfix. |
| 11:42 |
mmorgan |
If I'm understanding your question, yes, it's only an override to the allowed renewals, doesn't affect the durations. |
| 11:45 |
jboyer-isl |
mmorgan: thanks. I was concerned that never defining renewals in that table would lead to no renewals for anything, but I had been assigning a couple circ_mods the wrong duration rules. |
| 11:56 |
jeff |
psql:value_init.sql:220: ERROR: invalid input syntax for type money: "COST" |
| 11:57 |
jeff |
it's that time again. :P |
| 12:25 |
|
gdunbar joined #evergreen |
| 12:25 |
|
goooood joined #evergreen |
| 12:54 |
|
kitteh_ joined #evergreen |
| 13:08 |
|
smyers__ joined #evergreen |
| 13:15 |
rfrasur |
MARC punctuation is dumb |
| 13:16 |
dbs |
MARC punctuation is dumb / |
| 13:17 |
csharp |
dbs++ |
| 13:17 |
rfrasur |
exactly / |
| 13:24 |
|
timhome joined #evergreen |
| 13:27 |
* gmcharlt |
feels incomplete |
| 13:27 |
gmcharlt |
hmm |
| 13:27 |
gmcharlt |
MARC punctuation is dump / Tennant, Roy |
| 13:27 |
gmcharlt |
that's better! |
| 13:27 |
gmcharlt |
s/dump/dumb/ |
| 13:28 |
rfrasur |
MARC punctuation is dumb / Tennant, Roy. |
| 13:28 |
|
misilot joined #evergreen |
| 13:29 |
rfrasur |
I don't understand why we can't just stop it. If people are still typing cards, they can just type whatever they want now....all higgledy piggledy. |
| 13:29 |
dbs |
Have you read "MARC punctuation is dumb / Tennant, Roy." yet? |
| 13:30 |
|
misilot left #evergreen |
| 13:30 |
rfrasur |
oh, it's a real thing? |
| 13:30 |
* rfrasur |
obviously hasn't. |
| 13:30 |
* rfrasur |
hates MARC and reads nothing about it unless necessary. |
| 13:31 |
dbs |
rfrasur: no, i was trying to make a point about how the rules make it difficult to use the 245 elements in anything but a very specific context without munging |
| 13:31 |
rfrasur |
sorry, I wrecked your joke |
| 13:32 |
dbs |
rfrasur: not at all! |
| 13:33 |
paxed |
is there a way to specify what marc fields are required? preferably per marc template? |
| 13:33 |
rfrasur |
That's good. Technical services is making my brain not work right. |
| 13:34 |
jeff |
paxed: short of using a template to "suggest" the tags/fields by presenting them to the user, i don't think there is any mechanism at current to require a subset of fields, or require that they validate in a certain way, etc. |
| 13:34 |
rfrasur |
hmm, paxed...you'll have to explain more...maybe. Our rule is generally...if you can find the information ALL the fields are required (unless they're local fields in which case NONE of those are allowed) |
| 13:35 |
rfrasur |
it'd be lovely if there was some validating...but yeah. I envision angry librarians with flaming eyes and filed teeth storming through the stacks....all the stacks. |
| 13:36 |
paxed |
rfrasur: it's possible to delete all other fields in the editor (except ldr and 00x) - but that produces a rather useless record. |
| 13:37 |
rfrasur |
yeah, it is...but it's generally policy stuff that dictates required fields as far as I know. |
| 13:37 |
paxed |
jeff: ah. the validation would've been my next question. (i was thinking of regex, but that might not be enough in all the cases) |
| 13:37 |
rfrasur |
I know only the basics and enough to keep from being thrown out into the streets. |
| 13:38 |
paxed |
rfrasur: right, but policy doesn't prevent user, ahem, "creativity" ... |
| 13:38 |
rfrasur |
It doesn't. Hence the state of our bib db. |
| 13:38 |
jeff |
yeah. many tuits would be required to have a semi-validating marc editor which warned on what it believed to be a problem record, giving options to go back and fix or to press on but flag the record for later review. |
| 13:39 |
paxed |
at least some options to set simple regexps for some fields would be useful, and wouldn't be too hard to code, i guess. |
| 13:40 |
jeff |
of course, in addition to the tuits required, there's always the chance that nobody will ever go back and review, or that minor errors in the validation combined with slow-moving changes to the validation rules would result in 'workarounds' to avoid the warning... |
| 13:40 |
jeff |
...which would then be worse than the original issue |
| 13:40 |
jeff |
eesh, i'm not very optimistic there. sorry. :-) |
| 13:40 |
tsbere |
The system already throws out the worst of the worst offenders. Like when catalogers somehow try and submit an empty tag. Though more due to the backend barfing on them than anything else. |
| 13:41 |
* tsbere |
hates those tickets. "I can't save this MARC!" when the MARC is apparently invalid enough to make the backend choke on it |
| 13:51 |
|
mjingle joined #evergreen |
| 13:52 |
gmcharlt |
jeff: ah yes, the good old "fix the error message, not the problem" problem |
| 14:02 |
jboyer-isl |
MARC-- |
| 14:02 |
jboyer-isl |
I'm just seeing the punct talk. |
| 14:02 |
rfrasur |
;), it's still current though. |
| 14:03 |
|
smyers_ joined #evergreen |
| 14:08 |
jboyer-isl |
I had about 40 lines in JCPL's custom receipt formatting code to "fix" all the MARC-isms in our reciepts. |
| 14:09 |
rfrasur |
oy, I'd also prefer not to think about custom receipts right now. It's on the agenda for this week. Meh. |
| 14:10 |
* rfrasur |
thinks about corn chowder instead. |
| 14:19 |
jcamins |
rfrasur: I had delicious clam chowder for lunch. It was much better than custom receipts. |
| 14:19 |
kmlussier |
@love clam chowder |
| 14:19 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves clam chowder. |
| 14:20 |
rfrasur |
I have no doubt that that's true. Of course, that's a low bar BUT still. |
| 14:20 |
rfrasur |
I've never had clam chowder. |
| 14:20 |
rfrasur |
in my whole life...not once. |
| 14:20 |
kmlussier |
rfrasur: I'll buy you some at the conference. |
| 14:20 |
rfrasur |
rock on :D |
| 14:20 |
kmlussier |
You can't go through life without trying clam chowder. |
| 14:20 |
jcamins |
rfrasur: really? Wow. |
| 14:20 |
rfrasur |
or you can just eat it with me. |
| 14:21 |
jcamins |
I didn't even use fresh clams to make it. I bought a package of frozen, pre-shucked clams, and the result was magnificent. |
| 14:21 |
kmlussier |
Well, yes, I wasn't just going to dump a bowl in your lap and run. |
| 14:21 |
rfrasur |
really. only been on the ocean a few times and clams weren't the priorities. |
| 14:21 |
rfrasur |
lol, kmlussier: I was just saying you didn't have to buy it. |
| 14:22 |
jeff |
we kinda' miss our custom receipts now that we're doing self checkout. |
| 14:22 |
rfrasur |
but if clams take like mussels, I'll pass. |
| 14:22 |
rfrasur |
hmm. s/take/taste |
| 14:22 |
kmlussier |
Mussels are sweeter. |
| 14:23 |
rfrasur |
The mussels I've had smelled like.... |
| 14:23 |
jcamins |
rfrasur: I don't really know if clams taste like mussels. I have a tendency to get violently ill whenever I eat mussels, so mostly mussels just taste like misery to me. |
| 14:23 |
jeff |
i had a request to re-implement our "you have borrowed X worth of materials, thank you for using the library!", but even faking it via the sip patron screen message looks like it's not going to catch the current session's items. |
| 14:23 |
jcamins |
Of course, I'm weird... I like crabs but not lobsters or shrimp. |
| 14:24 |
jcamins |
To eat. I'm sure all three make equally boring conversational partners. |
| 14:24 |
rfrasur |
jcamins++ |
| 14:25 |
|
dconnor joined #evergreen |
| 14:30 |
kmlussier |
rfrasur: I know a lot of people (my husband) who generally don't like clams, but like clam chowder. So it's worth a shot. |
| 14:30 |
* kmlussier |
will eat any shellfish that crosses her path and is therefore somewhat biased. |
| 14:33 |
rfrasur |
I'll give just about anything a shot. I've nearly started liking wine. Next is to learn to, in nothing else, appreciate cottage cheese. I figure clams have to be as good, if not better, than both of those. |
| 14:34 |
|
kitteh_ left #evergreen |
| 14:39 |
jcamins |
rfrasur: I like wine. Not cottage cheese, though. |
| 14:40 |
rfrasur |
I don't really LIKE wine, but we're starting to be able to tolerate one another. I hate cottage cheese and its family and its family friends. Seriously, it's spoiled milk dressed up in a |
| 14:41 |
kmlussier |
Wine alongside clam chowder is even better. :) |
| 14:41 |
rfrasur |
Thomas Kinkade painting (which is even more nauseating) |
| 14:41 |
rfrasur |
kmlussier: challenge accepted. |
| 14:53 |
|
dconnor joined #evergreen |
| 14:56 |
csharp |
rfrasur: have you seen the Thomas Kinkade Star Wars mashups? |
| 14:56 |
csharp |
http://www.wired.com/underwire/2013/11/star-wars-kinkade-art/#slideid-282711 |
| 14:57 |
rfrasur |
yes! It was a marked improvement. |
| 14:57 |
csharp |
ha |
| 14:57 |
rfrasur |
I wonder if Thomas Kinkade and Nicholas Sparks used to hang out. |
| 15:07 |
|
stevenyvr2 joined #evergreen |
| 15:25 |
|
ericar joined #evergreen |
| 15:50 |
pinesol_green |
[evergreen|Remington Steed] Docs: Fix leveloffset bug, raise REL NOTES level - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=31fc9d1> |
| 15:50 |
pinesol_green |
[evergreen|Remington Steed] Docs: Remove ref to missing included file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=76580f6> |
| 16:02 |
|
smyers__ joined #evergreen |
| 16:03 |
|
kbutler joined #evergreen |
| 16:16 |
|
Bmagic joined #evergreen |
| 16:19 |
Bmagic |
good day everyone, Anyone out there have an idea on which tree to bark when the staff client asks for the patron login/password while trying to place a hold for an item from the item search results? |
| 16:20 |
Bmagic |
It's as if the OPAC doesnt know that we are logged in already with the staff client |
| 16:33 |
dbs |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1036318 I think |
| 16:33 |
pinesol_green |
Launchpad bug 1036318 in Evergreen 2.4 "OPAC timeout within the client" (affected: 13, heat: 68) [Medium,Fix committed] |
| 16:40 |
|
rfrasur joined #evergreen |
| 16:41 |
|
hopkinsju joined #evergreen |
| 16:42 |
Bmagic |
dbs: Thank you! That is giving us ideas |
| 16:45 |
jeff |
Bmagic: that fix should solve the problem you described -- but let me know if it does not. I'm interested in seeing the bug stay dead. :-) |
| 16:46 |
jeff |
Bmagic: good confirmation symptom is if you have at least one TPAC tab open and idle in the background and it has been returned to the "home" page of your catalog. |
| 16:46 |
Bmagic |
dbs: Yes, we are all over this, we should have an answer shortly: we are using 2.4.1 |
| 16:47 |
jeff |
Bmagic: if you find that in a staff client where you're experiencing the issue, I'm confident that the fix in that branch will resolve the issue. |
| 16:49 |
dbs |
jeff++ |
| 17:07 |
|
mrpeters left #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:12 |
rfrasur |
it's a good day when the printer that wasn't working is now. |
| 17:24 |
|
linuxhiker joined #evergreen |
| 17:24 |
linuxhiker |
I am getting a compile error for 2.2.5: checking for libdbi pgsql driver (dynamic load). but ldconfig: dbi/lib/dbd: |
| 17:24 |
linuxhiker |
libdbdpgsql.so -> libdbdpgsql.so |
| 17:25 |
linuxhiker |
and I also passed the --with-dbi option |
| 17:31 |
Bmagic |
dbs: the Simon Mai (simonmai) wrote on 2013-07-11: post on the launchpad bug had a 7 step process to reproduce the error. That did not make since to me because it would time out the whole staff client. Which means, we would expect the login prompt when asking to place a hold. With that said, I think we needed to introduce a new variable: tabs! |
| 17:32 |
Bmagic |
So, get a patron on the screen, Click holds, Click place hold, search for an item. Let that tab go stale while using another tab keeping the staff client active (keeping it from hitting the inactivity cap), then refer back to that tab and we notice that the search results go back to the search form |
| 17:33 |
|
ldwhalen joined #evergreen |
| 17:34 |
Bmagic |
dbs: And then we get the error, every single time. We applied the OPAC patch and that error went away (the search results essentially did not delete the cookie because it had the timeout on the page! It all makes more since now |
| 17:40 |
hopkinsju |
dbs++ |
| 17:40 |
hopkinsju |
dyrcona++ |
| 17:41 |
hopkinsju |
jeff++ |
| 17:41 |
hopkinsju |
Thanks for all the hard work nailing down 1036318, that's been bothering us for a while. |
| 17:59 |
linuxhiker |
problem solved (bad -L) thanks! |
| 18:01 |
Bmagic |
When load balancing Evergreen app servers, is it possible that the staff client requests could be sent to a different app server that the client had not authenticated against previously? The question could also be: Does the load balancer need to be cookie aware? |
| 18:03 |
|
rfrasur joined #evergreen |
| 18:05 |
|
DPearl1 joined #evergreen |
| 18:06 |
|
yboston left #evergreen |
| 18:09 |
gmcharlt |
Bmagic: not necessary; all of the app servers should be pointed at the same memcached instance, where current user sessions are stored |
| 18:56 |
|
linuxhiker joined #evergreen |
| 19:17 |
|
linuxhiker1 joined #evergreen |
| 20:31 |
|
stevenyvr2 left #evergreen |
| 20:59 |
|
mjingle left #evergreen |
| 21:17 |
|
kmlussier joined #evergreen |
| 21:59 |
|
phasefx2 joined #evergreen |
| 22:15 |
|
smyers_ joined #evergreen |
| 22:32 |
|
hopkinsju joined #evergreen |
| 23:08 |
|
linuxhiker joined #evergreen |
| 23:30 |
|
stevenyvr2 joined #evergreen |
| 23:31 |
|
stevenyvr2 left #evergreen |
