| Time |
Nick |
Message |
| 06:56 |
|
rjackson_isl_hom joined #evergreen |
| 07:31 |
|
rfrasur joined #evergreen |
| 07:39 |
|
collum joined #evergreen |
| 07:49 |
|
BDorsey joined #evergreen |
| 07:52 |
|
rjackson_isl_hom joined #evergreen |
| 08:08 |
|
mantis1 joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 10:09 |
|
jvwoolf joined #evergreen |
| 11:35 |
|
rfrasur_ joined #evergreen |
| 11:36 |
|
rfrasur_ joined #evergreen |
| 11:38 |
|
BAMkubasa joined #evergreen |
| 11:42 |
BAMkubasa |
Is the difference between action.transit_copy and action.hold_transit_copy that transit_copy is a record of things moving to and fro, while action.hold_transit_copy is specifically things that are headed one direction to fill a hold? |
| 11:43 |
BAMkubasa |
I'm trying to figure out if I'm correctly basing my resource sharing statistics on action.hold_transit_copy where hold is not null, and why in 47k cases, action.hold_transit_copy.hold is in fact null |
| 11:46 |
|
rfrasur_ joined #evergreen |
| 11:53 |
|
BDorsey joined #evergreen |
| 11:53 |
Dyrcona |
BAMkubasa: That is exactly correct. There will be entries in action.transit_copy for everything in transit. The action.hold_transit_copy has only those that are going to fill holds and includes the id of the hold that they are going to fill. |
| 11:54 |
BAMkubasa |
yay! thanks |
| 11:54 |
BAMkubasa |
any idea why the hold field may be blank at odd times in action.hold_transit_copy? |
| 11:55 |
berick |
BAMkubasa: if the hold was aged/deleted |
| 11:56 |
BAMkubasa |
gotcha. only 0.6% in our database |
| 12:09 |
|
rfrasur joined #evergreen |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:24 |
|
rfrasur joined #evergreen |
| 12:34 |
|
collum joined #evergreen |
| 12:35 |
|
collum joined #evergreen |
| 12:38 |
|
rfrasur joined #evergreen |
| 15:42 |
Bmagic |
is this function in tt2's ctx.get_ccvm created on the fly? |
| 15:42 |
berick |
Bmagic: yes |
| 15:42 |
Bmagic |
so when you pass an ID number into that function, the code eventually runs a sql query against config.coded_value_map ? |
| 15:44 |
berick |
Bmagic: right, it creates a editor call that results in a cstore query |
| 15:45 |
Bmagic |
for some reason, it's returning nothing, but when I query that table, for the ID number that the code is passing, there is stuff. I wonder if I have a fm_IDL issue |
| 15:46 |
Dyrcona |
Bmagic: It's created in the loop at about line 346 in EGCatloader::Util. |
| 15:47 |
Bmagic |
thanks, I think* the function exists in the stack, but it's not returning anything..... or maybe the function doesn't exist |
| 15:47 |
Dyrcona |
You might have an IDL issue. |
| 15:48 |
Dyrcona |
It loops through the IDL classes creating the helper functions. |
| 15:48 |
Bmagic |
is there a sanity check util somewhere for fm_IDL.xml ? |
| 15:50 |
Dyrcona |
Well, you can use xmllint from libxml2-utils to see if it valid. |
| 15:51 |
Dyrcona |
Was the CCVM created recently? It could be the cache value is empty. |
| 15:53 |
Bmagic |
hmm, cache value? |
| 15:54 |
Dyrcona |
Looks like the get_{idl} function ends up calling the list function and looks through the list in memcached, so if the entry was made recently, there's a chance it might not show up. I could also be misunderstanding the code. |
| 15:55 |
Dyrcona |
Yeah. Looks like the autogenerated functions use memcached. |
| 15:55 |
Bmagic |
memcached could be returning the value without querying the db... |
| 15:55 |
Bmagic |
interesting |
| 15:56 |
Dyrcona |
Right. If the key exists and points to an empty value you could see what you're seeing I think. |
| 15:56 |
Bmagic |
I suppose I could confirm that with a clever query against memcached.... any help on that syntax? |
| 15:57 |
berick |
Bmagic: have you reloaded Apache? |
| 15:57 |
Bmagic |
yes |
| 15:57 |
berick |
i think it only uses memcache for certain types of values |
| 15:57 |
berick |
otherwise, just a locally cached value |
| 15:58 |
Bmagic |
browser cache? apache cache maybe? |
| 15:58 |
Bmagic |
on a test machine, the variable looks like this: $VAR1 = bless( [569,'icon_format','eaudio','E-audio',undef,'t','E-audio','f',undef], 'Fieldmapper::config::coded_value_map' );node |
| 15:59 |
Dyrcona |
The memcache key looks like "EGWeb.$locale.$hint." where $locale is the current locale (probably en-US) and $hint is the IDL classs: ccvm. |
| 15:59 |
Bmagic |
but on the broken system: $VAR1 = '' |
| 16:00 |
Dyrcona |
The list will have list appended, so : "EGWeb.en-US.ccvm.list" or something like that. |
| 16:02 |
Dyrcona |
I'm not sure what the locale is going to look like. |
| 16:02 |
Bmagic |
telnet into 11211 on the memcached server. then issue this command: "get EGWeb.en-US.ccvm.list" ? |
| 16:03 |
Dyrcona |
You can try that. I've not looked up keys very often in memcached. |
| 16:04 |
Bmagic |
that must not be the keyname |
| 16:06 |
Bmagic |
get egweb.en-us.ccvm.list get EGWeb.en-US.list get EGweb.list yields nada |
| 16:06 |
Dyrcona |
I'm not sure what the locale is gonna be. try EGWeb..ccvm.list. |
| 16:11 |
Bmagic |
I see what you mean |
| 16:11 |
Bmagic |
I've tried a lot of combo's |
| 16:13 |
Bmagic |
it looks like the code ends the key with another period. but that doesn't hit either |
| 16:13 |
Dyrcona |
Well, list is added after the period for the list data. |
| 16:14 |
Dyrcona |
If it's missing in the cached list that would explain it. |
| 16:15 |
Dyrcona |
The key may be modified on its way through $memcache->get_cache |
| 16:15 |
Bmagic |
hmmm |
| 16:16 |
Dyrcona |
The get function is created around line 379 in master it looks like. |
| 16:16 |
Dyrcona |
It's definitely using cache. |
| 16:16 |
Bmagic |
agreed, I guess I can always restart memcached |
| 16:17 |
berick |
memcdump --servers 127.0.0.1:11211 |
| 16:17 |
berick |
(change to suit) |
| 16:17 |
Dyrcona |
:) |
| 16:18 |
Dyrcona |
The reason I was saying to look at the list key is because on line 382, it searches the list if it doesn't find the key directly in the cache. |
| 16:19 |
Dyrcona |
But yeah, memcdump should dump it all. |
| 16:19 |
Bmagic |
oh yeah memcdump... looking into that |
| 16:20 |
Bmagic |
bingo: EGWeb.en_us.ccvm.list |
| 16:20 |
Dyrcona |
Ah. local is lowercase. |
| 16:21 |
Dyrcona |
locale, even... Good to know. |
| 16:21 |
Bmagic |
that key doesn't exist on the broken system |
| 16:22 |
Bmagic |
and if that key doesn't exist.... the code breaks? |
| 16:23 |
Dyrcona |
So, the code in EGWeb is looking the values up in memcached and if there's something there, it's not looking it up in the database, so yeah. |
| 16:24 |
Dyrcona |
So, if it's not in the list, I don't think you can look it up using $ctx->get_ccvm. |
| 16:25 |
Bmagic |
the code makes me feel like if the key doesn't exist, it would create it? |
| 16:27 |
Dyrcona |
It builds the list_ccvm function, then the get_ccvm function. The latter looks things up in the list function. If the data is not in the list, then get can't retrieve it. |
| 16:28 |
Dyrcona |
I could be wrong, but that's how I read it. |
| 16:30 |
Bmagic |
sounds good to me. I'll just have to wait till night |
| 16:31 |
Dyrcona |
If you empty out the list key, it might reload. I think it works like that. berick would know better than I. |
| 16:31 |
Bmagic |
that key isn't in the cache |
| 16:32 |
Bmagic |
it exists on my test system, but not on the broken system |
| 16:37 |
berick |
the only thing that would prevent it from getting added to the cache is if the value for the requested ID is in the process-level cache |
| 16:37 |
berick |
but if you reload Apache, then that should be moot |
| 16:37 |
berick |
may restart apache instead *shrug* |
| 16:38 |
Bmagic |
I've restarted apache2 on the brick that I'm working with |
| 16:38 |
berick |
... and in order for it to get into the process cache, it would have to have gone through the memcache steps anyway |
| 16:38 |
berick |
so, yeah, it should be in the cache regardless |
| 16:43 |
Dyrcona |
I'm thinking the memcahed list was made before this particular ccvm entry existed, so this key never made it to memcached. There's probably some magic going on with cache map that I don't understand, though. |
| 16:44 |
Bmagic |
if the memcached server ran out of memory, maybe that key was evicted. The stats report that there have been some evictions during it's runtime |
| 16:45 |
Bmagic |
evictions: 1848042 |
| 16:51 |
Dyrcona |
Could be, but the code is looking in the EGWeb.en-us.ccvm.list, so if it's not there, I don't know how it would get loaded. |
| 17:02 |
* Dyrcona |
calls it a week. |
| 17:34 |
Bmagic |
berick: any thoughts on using that messagebee code for autorenewal notices? |
| 17:36 |
Bmagic |
I think I need to create a new xml template, one that brings in the json data from udata |
| 17:38 |
berick |
Bmagic: yes, just started doing that in fact. |
| 17:38 |
Bmagic |
oh nice |
| 17:39 |
* berick |
finds the patch |
| 17:39 |
Bmagic |
oh, so it's done |
| 17:45 |
berick |
Bmagic: https://github.com/berick/evergreen-xml-notices/commit/6b0b2e9c25e1e025971d07992a9f03178982d350 |
| 17:45 |
berick |
yeah, we're live |
| 17:45 |
Bmagic |
berick++ |
| 17:52 |
Bmagic |
gnight all! Have a great 2 weeks. Have a good bug squashing next week. I'm out till August 1st. |
