| Time |
Nick |
Message |
| 07:46 |
|
collum joined #evergreen |
| 08:06 |
|
BDorsey joined #evergreen |
| 08:29 |
|
kworstell-isl joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:46 |
|
Christineb joined #evergreen |
| 08:49 |
|
rfrasur joined #evergreen |
| 08:59 |
|
jvwoolf joined #evergreen |
| 09:01 |
|
Dyrcona joined #evergreen |
| 10:29 |
csharp_ |
PINES has had dual memcache servers since I began here in 2008 - we have them listed in opensrf.xml by IP address, each as <server> elements - I'm troubleshooting a NO SESSION issue for a library and I'm wondering - what if Evergreen hits the cache server that doesn't have the session key? I'm assuming that it does the obvious thing and just fails and returns NO SESSION? |
| 10:30 |
Dyrcona |
csharp_: That shouldn't happen if things are configured properly and all server can access both memcached servers. The server is part of the key to look up. |
| 10:30 |
Dyrcona |
s/server/Evergreen bricks/utility servers/ |
| 10:30 |
csharp_ |
ok - yes, all servers see both memcache servers |
| 10:31 |
csharp_ |
ah - good to know that the server is part of the key - I figured that had to be true, but started doubting |
| 10:31 |
Dyrcona |
The session could have expired or been evicted because of memory exhaustion. |
| 10:31 |
csharp_ |
that seems unlikely, but that's a theory |
| 10:32 |
csharp_ |
(mem exhaustion that is) |
| 10:32 |
csharp_ |
if a session expires, memcache just releases it without informing anyone, right? |
| 10:32 |
Dyrcona |
CW MARS used to run 3 memcached servers with something like 4 to 6 GB each for cache. |
| 10:32 |
csharp_ |
so there wouldn't be log evidence of such a deletion |
| 10:33 |
Dyrcona |
If the cache time expires that might happen. IIRC a lifetime can be set on cached items. |
| 10:33 |
Dyrcona |
I'm not 100% certain what happens with expired session keys. I'd have to dig through the code again. |
| 10:34 |
berick |
yes they just disappear when they expire |
| 10:34 |
berick |
*poof* |
| 10:58 |
|
kworstell_isl joined #evergreen |
| 11:18 |
csharp_ |
Dyrcona: berick: thanks for the responses! |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:42 |
|
collum joined #evergreen |
| 12:55 |
|
stephengwills joined #evergreen |
| 13:22 |
|
kmlussier joined #evergreen |
| 13:50 |
|
kworstell-isl joined #evergreen |
| 14:58 |
gmcharlt |
re the releases, now declaring a temporary freeze for rel_3_8, rel_3_9, and rel_3_10 |
| 14:58 |
jeff |
"which server do I ask" is a decision made by the client based on the key, but it's not part of the key itself. |
| 14:59 |
jeff |
it's a hashing/bucket function that the client implements |
| 14:59 |
gmcharlt |
building will move to the security repo for the moment given the security fixes that are to be included, with a follow-up sync of rel_3_* after the releases |
| 15:01 |
jeff |
if your list of servers changes and your client isn't using some form of consistent hashing, everything gets jumbled up. in our case, with sessions, where we have no fallback for a cache miss, that kind of thing would be quite disruptive. |
| 15:02 |
pinesol |
News from commits: LP # 1965447: adjust scoping of item tags Angular Holdings Editor <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2845dc07d156e607ada2aab25955524e4d067125> |
| 15:03 |
jeff |
if your servers list is relatively stable and you don't have reason to believe that you're using clients with different hashing methods (if it's been working fine for a while and you haven't changed anything that's probably a safe guess), the missing session most probably more likely evicted for space or time reasons, or it was deleted (but you probably looked for that in logs already) |
| 15:03 |
jeff |
s/relatively stable/completely stable/ -- would be a better way of putting that in this context. |
| 15:08 |
* gmcharlt |
claims 1361 |
| 15:18 |
jeff |
other than TTL expiry, memcached can evict things "early" for a number of reasons, and not just when newer objects push older objects out: the way that memcached allocates memory into slabs containing other similarly-sized objects means that your session object may be pushed out by some other similarly-sized object, even if it isn't as old as some other objects. |
| 15:36 |
|
jihpringle joined #evergreen |
| 15:59 |
Dyrcona |
Anyone ever really messed with report templates in the database? By that I mean written some SQL or Perl to yank templates out, remove fields, add fields, rename fields, etc.? |
| 16:00 |
berick |
just regexp_replace() |
| 16:00 |
Dyrcona |
I seem to recall changing the alias of some fields in a couple of templates with SQL in the past, but not added or removed fields. |
| 16:00 |
gmcharlt |
yeah, like berick, just a tiny bit |
| 16:01 |
Dyrcona |
That will work for adding fields? What about the relation hash? |
| 16:02 |
berick |
yeah i didn't add fields, just tweaked params, labels |
| 16:03 |
Dyrcona |
I'll see if I can figure out the hash code.... |
| 16:04 |
Dyrcona |
I'm concerned that they're really asking for something like a coalesce when they say "Add the preferred name to report templates." |
| 16:05 |
Dyrcona |
Guess I have research to do before 1:00 p.m. tomorrow. |
| 17:02 |
|
stephengwills left #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:39 |
|
jihpringle joined #evergreen |
