| Time |
Nick |
Message |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 08:19 |
|
agoben joined #evergreen |
| 08:36 |
|
remingtron joined #evergreen |
| 08:42 |
|
collum joined #evergreen |
| 08:51 |
|
kmlussier joined #evergreen |
| 08:52 |
|
rlefaive joined #evergreen |
| 09:00 |
kmlussier |
@coffee [someone] |
| 09:00 |
* pinesol_green |
brews and pours a cup of Brazil Fazenda Boa Vista, and sends it sliding down the bar to _bott_ |
| 09:00 |
kmlussier |
@tea [someone] |
| 09:00 |
* pinesol_green |
brews and pours a pot of 2006 Fengqing Raw Pu-erh Tea Tuocha, and sends it sliding down the bar to rjackson_isl (http://ratetea.com/tea/teavivre/2006-fengqing-raw-pu-erh-tea-tuocha/7065/) |
| 09:00 |
_bott_ |
Why thank you! |
| 09:00 |
* _bott_ |
sips on my Folgers and waits |
| 09:01 |
rjackson_isl |
sounds interesting kmlussier! |
| 09:04 |
|
Dyrcona joined #evergreen |
| 09:06 |
|
dbwells joined #evergreen |
| 09:11 |
|
mmorgan joined #evergreen |
| 09:29 |
|
terran joined #evergreen |
| 09:30 |
|
jvwoolf joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:43 |
|
rlefaive joined #evergreen |
| 09:48 |
|
rlefaive joined #evergreen |
| 09:52 |
|
littlet joined #evergreen |
| 09:53 |
* dbs |
wonders if we can get Apple infected with a virus that inserts Service Worker support code the Safari code base |
| 09:53 |
bshum |
dbs: From the little I read yesterday, it sounds like those Safari dev previews are working on adding it, but it's still work-in-progress stuff for the last year+ |
| 09:54 |
dbs |
bshum: yeah, trust me i know |
| 09:55 |
gmcharlt |
dbs: I suspect we'd find that, in that instance, Apple's defense is perfect |
| 09:55 |
dbs |
maybe it will arrive in time for EG 4.0 |
| 09:55 |
csharp |
dbs++ |
| 09:55 |
gmcharlt |
since we control the definition of 4.0... WE CAN MAKE THAT HAPPEN!!! |
| 09:56 |
csharp |
@blame apple |
| 09:56 |
pinesol_green |
csharp: apple typed Google into Google; broke the Internet. |
| 09:56 |
* dbs |
wonders how well Hatch is running on iOS these days. hahaha |
| 09:56 |
gmcharlt |
(in time) ;) |
| 09:56 |
dbs |
@ana grim humour |
| 09:56 |
pinesol_green |
dbs: Im rough rum |
| 09:56 |
csharp |
pinesol_green: ell played, my friend. Well played. |
| 09:56 |
pinesol_green |
csharp: http://cat.evergreen-ils.org.meowbify.com/ |
| 09:56 |
csharp |
*w*ell |
| 10:31 |
|
Christineb joined #evergreen |
| 10:52 |
|
rjackson_isl joined #evergreen |
| 11:00 |
|
bos20k joined #evergreen |
| 11:48 |
|
littlet joined #evergreen |
| 12:03 |
|
ngf42 joined #evergreen |
| 12:04 |
|
khuckins joined #evergreen |
| 12:39 |
|
rlefaive joined #evergreen |
| 12:43 |
|
jihpringle joined #evergreen |
| 13:05 |
|
bos20k joined #evergreen |
| 13:09 |
|
rlefaive joined #evergreen |
| 13:16 |
|
derekz joined #evergreen |
| 13:39 |
|
remingtron_ joined #evergreen |
| 14:11 |
|
rlefaive joined #evergreen |
| 14:22 |
mmorgan |
We're looking at making use of the --soft-retarget-interval flag in the new hold targeter based on recent IRC discussions. |
| 14:23 |
mmorgan |
We've been running the hold targeter every 15 minutes since the beginning. We have the retarget interval set to 24 hours. |
| 14:23 |
mmorgan |
It sounds like we can add a --soft-retarget-interval '30 minute' flag to our existing cron job, and that will retarget holds with a prev_check_time that's 30 minutes old and have no current_copy, in addition to those eligible for full retargeting. |
| 14:23 |
mmorgan |
Am I understanding this correctly? |
| 14:31 |
mmorgan |
^^berick or Bmagic? |
| 14:46 |
Bmagic |
mmorgan: sorry, just getting back to my workstation |
| 14:46 |
mmorgan |
no problem! |
| 14:46 |
Bmagic |
mmorgan: I would slow the cronjob down to 30 minutes with the soft retarget set to 30 minutes |
| 14:46 |
Bmagic |
and introduce a second cronjob during the night without that flag |
| 14:49 |
mmorgan |
So that would make our full retargeting all happen overnight rather than in 15 minute chunks throughout the day as it happens now. |
| 14:49 |
Bmagic |
depending on how many holds you have on average, it might take the better part of 30 minutes to finish anyway |
| 14:49 |
Bmagic |
mmorgan: right |
| 14:50 |
Bmagic |
The 30 minute job would catch all of the holds that do not already have a copy, so it might achieve what you are trying to achieve every 15 minutes anyway |
| 14:50 |
Bmagic |
and the overnight one will update the targeted copy holds to the next available copy (if it wasn't captured) |
| 14:50 |
Bmagic |
just like you would expect |
| 14:52 |
mmorgan |
Having a rolling full regargeting going on throughout the day makes more sense to me, rather than processing them all overnight. |
| 14:53 |
Dyrcona |
mmorgan: You'd think so, but it really make very little difference. |
| 14:53 |
Dyrcona |
We do it every 15 minutes at C/W MARS and MVLC did it once per day. |
| 14:56 |
Dyrcona |
For the logs: The default hard retarget interval is 24 hours, so it only retargets each hold once per day anyway. |
| 14:56 |
Dyrcona |
Hold targeter v2 lets you change that and a bunch of other options more easily. |
| 14:57 |
* mmorgan |
will continue to explore those options :) |
| 14:57 |
mmorgan |
Bmagic++ |
| 14:57 |
mmorgan |
Dyrcona++ |
| 14:58 |
Bmagic |
sorry the phone rang |
| 14:58 |
Dyrcona |
IIRC, Bmagic uses a 2 day hard retarget with the 30 minute soft retarget interval. Is that to stop it from hard targeting holds at all? |
| 14:58 |
Bmagic |
|| what Dyrcona said |
| 14:58 |
kmlussier |
mmorgan: Out of curiousity, why do you prefer retargeting throughout the day? Is it a concern about how long it takes? |
| 14:59 |
Bmagic |
Dyrcona: the 2 day value on the 30 minute cron is to prevent it from retargeting already-targeted holds |
| 14:59 |
Dyrcona |
Bmagic: Right, that's what I meant, but fingers.... :) |
| 14:59 |
Dyrcona |
Bmagic++ |
| 14:59 |
Bmagic |
presuming that the nightly one updated prev_check_time |
| 15:00 |
Dyrcona |
I guess if one wanted to keep retargeting already targeted holds throughout the day, the nightly one could be skipped and a standard interval used on the one that runs periodically. |
| 15:01 |
mmorgan |
kmlussier: partly, and just spreading them out. Rather than retarget all holds eligible for retargeting for that day overnight, do a 15 minute chunk at a time. So prev_check_times in holds are throughout the day, rather than all being essentially the same time during the night. |
| 15:01 |
Dyrcona |
Something for us to discuss here before our upgrade to 3.0. |
| 15:01 |
* mmorgan |
needs to run to a meeting. |
| 15:02 |
Dyrcona |
In practice, I've found it makes little difference doing them all over night versus multiple times a day, but no real quantifiable evidence. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:28 |
berick |
swtiched to nightly batches here back in Oct and no one noticed (except us on the back-end) |
| 15:29 |
* Dyrcona |
is considering running the same, but adding a soft-retarget interval. |
| 15:29 |
Dyrcona |
Meanin, continuing to run the hold targeter multiple times per hour. :) |
| 15:29 |
Dyrcona |
bleh.... fingers.... |
| 15:30 |
berick |
"alexa, tell IRC that I'm retargeting hourly" |
| 15:31 |
Dyrcona |
heh |
| 15:51 |
Dyrcona |
We also switched to running the fine generator just once an hour from twice an hour and no one noticed. :) |
| 15:52 |
pinesol_green |
[evergreen|Galen Charlton] LP#1745486: avoid retrieving user by id::numeric during auth init - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8410fda> |
| 16:00 |
Dyrcona |
gmcharlt++ berick++ # That one was a good catch. |
| 16:46 |
|
Jillianne joined #evergreen |
| 16:58 |
|
mmorgan joined #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:02 |
|
derekz left #evergreen |
| 17:43 |
|
kmlussier joined #evergreen |
| 17:47 |
|
Jillianne joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
