<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="description" content="IRC LOG for channel #evergreen" />
<meta name="viewport" content="width=device-width" />
<link rel="stylesheet" type="text/css" href="/s/style.css" title="Irclog Stylesheet" />
<link rel="shortcut icon" href="/s/favicon.ico" type="image/x-icon" />
<link rel="canonical"
href="/evergreen/2023-10-31" />
<title>IRC log for #evergreen, 2023-10-31</title>
</head>
<body>
<p><a href="http://evergreen-ils.org/"><img style="float:right; border:none"
src="/s/small_logo.jpg" alt="Evergreen ILS Website"/></a></p>
<h1>IRC log for #evergreen, 2023-10-31</h1>
<p>
<a href="/evergreen/2023-10-30" rel="prev">
← Previous day</a> |
<a href="/">Channels</a> |
<a href="/evergreen/">#evergreen index</a> |
<a href="/evergreen/today">Today</a> |
<a href="/evergreen/2023-11-01" rel="next">
Next day →</a> |
<a href="/evergreen/search">Search</a> |
<a href="http://www.google.com/search?q=site%3Airc.evergreen-ils.org+inurl%3Aevergreen">Google Search</a>
| <a href="/evergreen/2023-10-31/text">Plain-Text</a> |
<a href="/evergreen/2023-10-31/summary">summary</a>
| <a href="https://webchat.freenode.net/?channels=evergreen">Join Webchat</a>
</p>
<p>All times shown according to the server's local time.</p>
<div>
<span style="display: none;" id="filter_toggle"></span>
<span id="summary_container" />
</div>
<form action="#" name="summary_form" id="summary_form">
<span id="top" />
<table id="log" style="clear:both">
<tr class="head">
<th>Time</th>
<th>Nick</th>
<th>Message</th>
</tr>
<tr id="id_l2" class="new nick nick_jeff dark">
<td class="time" id="i_537214"><a href="/evergreen/2023-10-31#i_537214">00:09</a></td>
<td style="color: #001009" class="nick">jeff</td>
<td class="msg ">Bmagic: taking 4-6s to seq scan a table containing 26 rows is... neat. :-P</td>
</tr>
<tr id="id_l3" class="cont nick nick_jeff dark">
<td class="time" id="i_537215"><a href="/evergreen/2023-10-31#i_537215">00:11</a></td>
<td style="color: #001009" class="nick">jeff</td>
<td class="msg ">is SELECT * FROM config.display_field_map; slow?</td>
</tr>
<tr id="id_l4" class="new special">
<td class="time" id="i_537216"><a href="/evergreen/2023-10-31#i_537216">04:24</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">Guest13 joined #evergreen</td>
</tr>
<tr id="id_l5" class="new nick nick_Guest13 dark">
<td class="time" id="i_537217"><a href="/evergreen/2023-10-31#i_537217">04:26</a></td>
<td style="color: #45641e" class="nick">Guest13</td>
<td class="msg ">Hello, I have a question about evergreen software. Is there someone who can explain it to me in easy way :))</td>
</tr>
<tr id="id_l6" class="new special">
<td class="time" id="i_537218"><a href="/evergreen/2023-10-31#i_537218">06:24</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">redavis joined #evergreen</td>
</tr>
<tr id="id_l7" class="cont special">
<td class="time" id="i_537219"><a href="/evergreen/2023-10-31#i_537219">08:06</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">BDorsey joined #evergreen</td>
</tr>
<tr id="id_l8" class="cont special">
<td class="time" id="i_537220"><a href="/evergreen/2023-10-31#i_537220">08:35</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">mmorgan joined #evergreen</td>
</tr>
<tr id="id_l9" class="cont special">
<td class="time" id="i_537221"><a href="/evergreen/2023-10-31#i_537221">08:37</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">dguarrac joined #evergreen</td>
</tr>
<tr id="id_l10" class="cont special">
<td class="time" id="i_537222"><a href="/evergreen/2023-10-31#i_537222">08:54</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">smayo joined #evergreen</td>
</tr>
<tr id="id_l11" class="cont special">
<td class="time" id="i_537223"><a href="/evergreen/2023-10-31#i_537223">09:05</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">Dyrcona joined #evergreen</td>
</tr>
<tr id="id_l12" class="cont special">
<td class="time" id="i_537224"><a href="/evergreen/2023-10-31#i_537224">09:16</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">mantis1 joined #evergreen</td>
</tr>
<tr id="id_l13" class="cont special">
<td class="time" id="i_537225"><a href="/evergreen/2023-10-31#i_537225">09:21</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">sandbergja joined #evergreen</td>
</tr>
<tr id="id_l14" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537226"><a href="/evergreen/2023-10-31#i_537226">09:25</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">berick: I'm getting the following with the latest Redis branch for Opensrf: osrf_control -l --start-all</td>
</tr>
<tr id="id_l15" class="cont nick nick_Dyrcona dark">
<td class="time" id="i_537227"><a href="/evergreen/2023-10-31#i_537227">09:25</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">[auth] WRONGPASS invalid username-password pair, at /usr/share/perl5/Redis.pm line 311.</td>
</tr>
<tr id="id_l16" class="cont nick nick_Dyrcona dark">
<td class="time" id="i_537228"><a href="/evergreen/2023-10-31#i_537228">09:26</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">This is after a VM reboot, so it looks like the auto --reset-message-bus isn't always working.</td>
</tr>
<tr id="id_l17" class="cont nick nick_Dyrcona dark">
<td class="time" id="i_537229"><a href="/evergreen/2023-10-31#i_537229">09:26</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">This is what I have checked out/installed: 437e8c67 (HEAD -> collab/berick/lp2017941-opensrf-on-redis-v3, working/collab/berick/lp2017941-opensrf-on-redis-v3) LP2017941 Auto-reset bus accounts; simplify and fix</td>
</tr>
<tr id="id_l18" class="cont nick nick_Dyrcona dark">
<td class="time" id="i_537230"><a href="/evergreen/2023-10-31#i_537230">09:33</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">For the logs: `osrf_control -l --reset-message-bus` fixes it.</td>
</tr>
<tr id="id_l19" class="new nick nick_berick">
<td class="time" id="i_537231"><a href="/evergreen/2023-10-31#i_537231">09:38</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">Dyrcona: hm, ok. it does require a ./configure to rebuild the osrf_control</td>
</tr>
<tr id="id_l20" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537232"><a href="/evergreen/2023-10-31#i_537232">09:40</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Hmm. Maybe I just did make.</td>
</tr>
<tr id="id_l21" class="cont nick nick_Dyrcona dark">
<td class="time" id="i_537233"><a href="/evergreen/2023-10-31#i_537233">09:40</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">make should detect if ./configure is necessary, though.</td>
</tr>
<tr id="id_l22" class="new nick nick_Bmagic">
<td class="time" id="i_537234"><a href="/evergreen/2023-10-31#i_537234">09:47</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">jeff: that table doesn't exist config.display_field_map. I thought it was talking about metabib.display_entry</td>
</tr>
<tr id="id_l23" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537235"><a href="/evergreen/2023-10-31#i_537235">09:48</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">OK. Explicitly doing ./configure fixed it. That's probably a bug in how we're using autotools. Make with autotools is supposed to detect when configure is needed.</td>
</tr>
<tr id="id_l24" class="new nick nick_berick">
<td class="time" id="i_537236"><a href="/evergreen/2023-10-31#i_537236">09:49</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">Dyrcona: cool, good to know</td>
</tr>
<tr id="id_l25" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537237"><a href="/evergreen/2023-10-31#i_537237">09:49</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Bmagic: If you're still hunting the same thing from yesterday, metabib.display_entry is (I think), the only actual table involved in all of those views. There might be one other.</td>
</tr>
<tr id="id_l26" class="cont nick nick_Dyrcona dark">
<td class="time" id="i_537238"><a href="/evergreen/2023-10-31#i_537238">09:50</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Also, I'm trying to figure out why a bunch of checkins fail silently. I think I'll just override all events instead of play whack-a-mole.</td>
</tr>
<tr id="id_l27" class="new nick nick_Bmagic">
<td class="time" id="i_537239"><a href="/evergreen/2023-10-31#i_537239">09:51</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">jeff: lol, sorry, nevermind, that table does exist. select * takes .59</td>
</tr>
<tr id="id_l28" class="cont nick nick_Bmagic">
<td class="time" id="i_537240"><a href="/evergreen/2023-10-31#i_537240">09:51</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">Seq Scan on display_field_map cdfm (cost=0.00..1.32 rows=1 width=37) (actual time=6375.566..6375.573 rows=1 loops=1)"</td>
</tr>
<tr id="id_l29" class="cont nick nick_Bmagic">
<td class="time" id="i_537241"><a href="/evergreen/2023-10-31#i_537241">09:52</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">something is seriously wrong. I agree jeff. 6 seconds to seq scan a 26 row table. Doesn't make any sense</td>
</tr>
<tr id="id_l30" class="cont nick nick_Bmagic">
<td class="time" id="i_537242"><a href="/evergreen/2023-10-31#i_537242">09:53</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">Dyrcona: yep, same thing from yesterday</td>
</tr>
<tr id="id_l31" class="cont nick nick_Bmagic">
<td class="time" id="i_537243"><a href="/evergreen/2023-10-31#i_537243">09:54</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">Dyrcona:</td>
</tr>
<tr id="id_l32" class="cont nick nick_Bmagic">
<td class="time" id="i_537244"><a href="/evergreen/2023-10-31#i_537244">09:54</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">DB1: <a href="https://explain.depesz.com/s/srWZ" title="https://explain.depesz.com/s/srWZ">https://explain.depesz.com/s/srWZ</a></td>
</tr>
<tr id="id_l33" class="cont nick nick_Bmagic">
<td class="time" id="i_537245"><a href="/evergreen/2023-10-31#i_537245">09:54</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">DB2: <a href="https://explain.depesz.com/s/OWwJ" title="https://explain.depesz.com/s/OWwJ">https://explain.depesz.com/s/OWwJ</a></td>
</tr>
<tr id="id_l34" class="cont nick nick_Bmagic">
<td class="time" id="i_537246"><a href="/evergreen/2023-10-31#i_537246">09:55</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">I had a thought that maybe postgres "buffered" that table, and it was reusing a method that it used before. Instead of "re-thinking". I figured a postgres restart would have cleared it's brain and caused it to re-think stuff?</td>
</tr>
<tr id="id_l35" class="new nick nick_eeevil dark">
<td class="time" id="i_537247"><a href="/evergreen/2023-10-31#i_537247">09:57</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">Bmagic: I'm coming in late, and might have missed something, but the seq scan line you pasted at 9:51 (for me) says .007 milliseconds to scan cdfm, not 6 seconds</td>
</tr>
<tr id="id_l36" class="new nick nick_Bmagic">
<td class="time" id="i_537248"><a href="/evergreen/2023-10-31#i_537248">09:58</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">eeevil: I pasted an example of a fast one and a slow one. Both machines containing the same database. PG15, DB1->DB2 replicant. DB1 is slow, DB2 is fast. I decided to pg_dump DB1 and then delete the database, and pg_restore. Then resync DB2. Now their both slow</td>
</tr>
<tr id="id_l37" class="cont nick nick_Bmagic">
<td class="time" id="i_537249"><a href="/evergreen/2023-10-31#i_537249">09:59</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">I'm considering an index for config.display_field_map.name</td>
</tr>
<tr id="id_l38" class="new nick nick_eeevil dark">
<td class="time" id="i_537250"><a href="/evergreen/2023-10-31#i_537250">09:59</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">what I mean is, in "Seq Scan on display_field_map cdfm (cost=0.00..1.32 rows=1 width=37) (actual time=6375.566..6375.573 rows=1 loops=1)" the actual time is a start..finish range, measured in ms</td>
</tr>
<tr id="id_l39" class="new nick nick_Bmagic">
<td class="time" id="i_537251"><a href="/evergreen/2023-10-31#i_537251">10:00</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">eeevil: oh, so maybe I misunderstand where it's slow?</td>
</tr>
<tr id="id_l40" class="new nick nick_eeevil dark">
<td class="time" id="i_537252"><a href="/evergreen/2023-10-31#i_537252">10:01</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I think explain.depsesz might be confused, and leading you astray</td>
</tr>
<tr id="id_l41" class="new nick nick_Bmagic">
<td class="time" id="i_537253"><a href="/evergreen/2023-10-31#i_537253">10:01</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">where are you seeing the 6 second spike? metabib_field_pkey?</td>
</tr>
<tr id="id_l42" class="cont nick nick_Bmagic">
<td class="time" id="i_537254"><a href="/evergreen/2023-10-31#i_537254">10:07</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">the index didn't help</td>
</tr>
<tr id="id_l43" class="cont nick nick_Bmagic">
<td class="time" id="i_537255"><a href="/evergreen/2023-10-31#i_537255">10:07</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">another idea I had was to truncate metabib.display_entry and reingest</td>
</tr>
<tr id="id_l44" class="new nick nick_eeevil dark">
<td class="time" id="i_537256"><a href="/evergreen/2023-10-31#i_537256">10:11</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">yeah, I do see exactly where the 6s are coming from: JIT</td>
</tr>
<tr id="id_l45" class="cont nick nick_eeevil dark">
<td class="time" id="i_537257"><a href="/evergreen/2023-10-31#i_537257">10:12</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">it's right there in the JIT timing summary: Timing: Generation 30.673 ms, Inlining 29.530 ms, Optimization 3683.782 ms, Emission 2662.593 ms, Total 6406.579 ms</td>
</tr>
<tr id="id_l46" class="new nick nick_Bmagic">
<td class="time" id="i_537258"><a href="/evergreen/2023-10-31#i_537258">10:13</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">ah, all the way at the bottom</td>
</tr>
<tr id="id_l47" class="new nick nick_eeevil dark">
<td class="time" id="i_537259"><a href="/evergreen/2023-10-31#i_537259">10:14</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I would recommend turning off all the JIT options individually, and then consider turning them back on one at a time. proably start with inlining (and generation if needed for inlining, I don't recall if it is)</td>
</tr>
<tr id="id_l48" class="new nick nick_Bmagic">
<td class="time" id="i_537260"><a href="/evergreen/2023-10-31#i_537260">10:15</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">researching....</td>
</tr>
<tr id="id_l49" class="new nick nick_eeevil dark">
<td class="time" id="i_537261"><a href="/evergreen/2023-10-31#i_537261">10:16</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">(so, in defence of explain.depesz, it's doing the best it can to highlight the JIT slowdown, but it def does still require understanding of what's being presented)</td>
</tr>
<tr id="id_l50" class="new nick nick_Bmagic">
<td class="time" id="i_537262"><a href="/evergreen/2023-10-31#i_537262">10:19</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">eeevil++ # jit_above_cost = -1 fixed it</td>
</tr>
<tr id="id_l51" class="cont nick nick_Bmagic">
<td class="time" id="i_537263"><a href="/evergreen/2023-10-31#i_537263">10:19</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">good night that was bothering me</td>
</tr>
<tr id="id_l52" class="cont nick nick_Bmagic">
<td class="time" id="i_537264"><a href="/evergreen/2023-10-31#i_537264">10:20</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">6000ms down to 15ms</td>
</tr>
<tr id="id_l53" class="cont nick nick_Bmagic">
<td class="time" id="i_537265"><a href="/evergreen/2023-10-31#i_537265">10:20</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">so now I have to figure out what other things are broken with that disabled</td>
</tr>
<tr id="id_l54" class="new nick nick_berick dark">
<td class="time" id="i_537266"><a href="/evergreen/2023-10-31#i_537266">10:20</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">TIL about PG JIT</td>
</tr>
<tr id="id_l55" class="new nick nick_Bmagic">
<td class="time" id="i_537267"><a href="/evergreen/2023-10-31#i_537267">10:21</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">berick++ lol</td>
</tr>
<tr id="id_l56" class="cont nick nick_Bmagic">
<td class="time" id="i_537268"><a href="/evergreen/2023-10-31#i_537268">10:21</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">I had to Google TIL</td>
</tr>
<tr id="id_l57" class="cont nick nick_Bmagic">
<td class="time" id="i_537269"><a href="/evergreen/2023-10-31#i_537269">10:22</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">TIL about TIL</td>
</tr>
<tr id="id_l58" class="new nick nick_berick dark">
<td class="time" id="i_537270"><a href="/evergreen/2023-10-31#i_537270">10:22</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">heh</td>
</tr>
<tr id="id_l59" class="new nick nick_eeevil">
<td class="time" id="i_537271"><a href="/evergreen/2023-10-31#i_537271">10:31</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">disabling JIT shouldn't break anything. it'll just behave more like pg 10 or 11. which is to say, more predictable, sometimes a little slower, and sometimes (as here) much faster</td>
</tr>
<tr id="id_l60" class="new nick nick_Bmagic dark">
<td class="time" id="i_537272"><a href="/evergreen/2023-10-31#i_537272">10:33</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">eeevil++</td>
</tr>
<tr id="id_l61" class="new nick nick_eeevil">
<td class="time" id="i_537273"><a href="/evergreen/2023-10-31#i_537273">10:45</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">JIT is really good for DW and analytics, ESPECIALLY when you have, say, a pile GPUs and the citus column store extension installed and you're folding proteins or something. stuff where there's a LOT of data, it's extremely well controlled in type and datum size, but you don't know the cardinality or distribution of the data. TBH, that's basically the opposite of EG's data for the most part ;)</td>
</tr>
<tr id="id_l62" class="new nick nick_Bmagic dark">
<td class="time" id="i_537274"><a href="/evergreen/2023-10-31#i_537274">10:46</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">I didn't turn it completely off. There is a setting for just straight turning it off "jit = on"</td>
</tr>
<tr id="id_l63" class="cont nick nick_Bmagic dark">
<td class="time" id="i_537275"><a href="/evergreen/2023-10-31#i_537275">10:46</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">this is the one setting that I changed where it changed the outcome of the analyze: "jit_above_cost = -1"</td>
</tr>
<tr id="id_l64" class="cont nick nick_Bmagic dark">
<td class="time" id="i_537276"><a href="/evergreen/2023-10-31#i_537276">10:47</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">that fixed course reserves :)</td>
</tr>
<tr id="id_l65" class="cont nick nick_Bmagic dark">
<td class="time" id="i_537277"><a href="/evergreen/2023-10-31#i_537277">10:50</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">jeff jeffdavis : Pining you all just to make sure you see the fix. It should probably be baked into our install instructions come to think of it</td>
</tr>
<tr id="id_l66" class="new special">
<td class="time" id="i_537278"><a href="/evergreen/2023-10-31#i_537278">10:54</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">briank joined #evergreen</td>
</tr>
<tr id="id_l67" class="new nick nick_eeevil dark">
<td class="time" id="i_537279"><a href="/evergreen/2023-10-31#i_537279">10:55</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I'd recommend the install instructions just say "Do not turn on Postgres' JIT capabilities. Evergreen's queries, especially complex ones used for search, are intentionally tuned for non-JIT execution and JIT has been shown to be harmful in some circumstances." then, once we know how/when/what to use from the JIT toolbox, we can change that rec. just IMO...</td>
</tr>
<tr id="id_l68" class="cont nick nick_eeevil dark">
<td class="time" id="i_537280"><a href="/evergreen/2023-10-31#i_537280">10:57</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">the core problem is one of estimation -- we need to invest time/energy into finding the most likely universal cross-column and cross-table stats to configure, because PG will try to use JIT when the stats say "you're going to have to compare 1 BEEEELLION INTEGERS", and spend multiple seconds setting that up for a query, and then the stats were wrong and it compares, like, 3 rows.</td>
</tr>
<tr id="id_l69" class="cont nick nick_eeevil dark">
<td class="time" id="i_537281"><a href="/evergreen/2023-10-31#i_537281">10:59</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">but we can't simply blanket every instance in stats gathering config, because that's a speed issue both coming and going, and MOAR STATS is not necessarily better stats</td>
</tr>
<tr id="id_l70" class="new nick nick_Bmagic">
<td class="time" id="i_537282"><a href="/evergreen/2023-10-31#i_537282">11:00</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">I'll submit the change to our install instructions</td>
</tr>
<tr id="id_l71" class="new nick nick_berick dark">
<td class="time" id="i_537283"><a href="/evergreen/2023-10-31#i_537283">11:05</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: i'm working on a tech ref doc for redis bus addresses / login accounts. <a href="https://gist.github.com/berick/b1d26f7179b97635c71c9ac91ac38584" title="https://gist.github.com/berick/b1d26f7179b97635c71c9ac91ac38584">https://gist.github.com/berick/b1d26f7179b97635c71c9ac91ac38584</a></td>
</tr>
<tr id="id_l72" class="new nick nick_eeevil">
<td class="time" id="i_537284"><a href="/evergreen/2023-10-31#i_537284">11:07</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">berick++</td>
</tr>
<tr id="id_l73" class="cont nick nick_eeevil">
<td class="time" id="i_537285"><a href="/evergreen/2023-10-31#i_537285">11:07</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">thanks!</td>
</tr>
<tr id="id_l74" class="cont nick nick_eeevil">
<td class="time" id="i_537286"><a href="/evergreen/2023-10-31#i_537286">11:11</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">berick: so, right off the bat, I think I understood correctly that the first part of the bus address is pinned, and (right now) you couldn't have two separate instances running services and not seeing each other, right? to be able to have bus addresses and redis account paired is the thing I'm looking for, if by convention (some param that defaults to "opensrf" for the bus prefix) or explicitly/intentionally (the bus prefix is the login user name)</td>
</tr>
<tr id="id_l75" class="new nick nick_berick dark">
<td class="time" id="i_537287"><a href="/evergreen/2023-10-31#i_537287">11:13</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: 'opensrf' as part of the bus prefix is convention and unrelated to the redis account. just wanted it have some kind of prefix. running separate service instances on one Redis instance just means giving each its own domwin.</td>
</tr>
<tr id="id_l76" class="cont nick nick_berick dark">
<td class="time" id="i_537288"><a href="/evergreen/2023-10-31#i_537288">11:14</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">*domain</td>
</tr>
<tr id="id_l77" class="new nick nick_eeevil">
<td class="time" id="i_537289"><a href="/evergreen/2023-10-31#i_537289">11:15</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I was advocating for the user name as the prefix so that we don't have to have (maintain, update, restart) dns changes all the time</td>
</tr>
<tr id="id_l78" class="cont nick nick_eeevil">
<td class="time" id="i_537290"><a href="/evergreen/2023-10-31#i_537290">11:15</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">is there a reason /not/ to just make the prefix be the user that the redis-connecting thing uses?</td>
</tr>
<tr id="id_l79" class="new nick nick_berick dark">
<td class="time" id="i_537291"><a href="/evergreen/2023-10-31#i_537291">11:17</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: top of head, that would probably work, but would mean some router changes .. i think, need to verify</td>
</tr>
<tr id="id_l80" class="new nick nick_jeff">
<td class="time" id="i_537292"><a href="/evergreen/2023-10-31#i_537292">11:34</a></td>
<td style="color: #001009" class="nick">jeff</td>
<td class="msg ">eeevil++ imparting the JIT knowledge</td>
</tr>
<tr id="id_l81" class="new nick nick_eeevil dark">
<td class="time" id="i_537293"><a href="/evergreen/2023-10-31#i_537293">11:34</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">eeevil-- # being a curmudgeon re JIT ;)</td>
</tr>
<tr id="id_l82" class="new nick nick_jeff">
<td class="time" id="i_537294"><a href="/evergreen/2023-10-31#i_537294">11:35</a></td>
<td style="color: #001009" class="nick">jeff</td>
<td class="msg ">And agreed, I think explain.depesz.com might need to tweak its pre-JIT logic surrounding the exclusive column. no longer is it "the deepest node has nothing else consuming time"</td>
</tr>
<tr id="id_l83" class="new nick nick_berick dark">
<td class="time" id="i_537295"><a href="/evergreen/2023-10-31#i_537295">11:37</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: thinking through some options.. keeping the 'opensrf' prefix is simplest way forward (for ACL rules, code changes, etc.) but i think we could get the same benefit using router addresses like opesrf:router:$omain:$login -- then teach the services to register to specific routers by domain+login</td>
</tr>
<tr id="id_l84" class="new nick nick_eeevil">
<td class="time" id="i_537296"><a href="/evergreen/2023-10-31#i_537296">11:37</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">berick: hrm... I wouldn't think that would be necessary, since the router is named WRT the services and the clients (they know where to send router-distributed requests) and routers get registrations from the servers, so know where they should be sending messages to distributed. however, I have /not/ looked at the redis-ized router code, so I'm probably making assumptions about what's recorded and what's computed</td>
</tr>
<tr id="id_l85" class="cont nick nick_eeevil">
<td class="time" id="i_537297"><a href="/evergreen/2023-10-31#i_537297">11:38</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">the thing that removes is the ACL-based cross-"user" protection of queues, though</td>
</tr>
<tr id="id_l86" class="cont nick nick_eeevil">
<td class="time" id="i_537298"><a href="/evergreen/2023-10-31#i_537298">11:39</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">if the $login part is in the wildcard section of the ACL protection, then any client-user connection to redis can send requests at any service, right?</td>
</tr>
<tr id="id_l87" class="cont nick nick_eeevil">
<td class="time" id="i_537299"><a href="/evergreen/2023-10-31#i_537299">11:40</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I ... can't type. 2 lines up should be "I think that", not "the thing that"</td>
</tr>
<tr id="id_l88" class="new nick nick_berick dark">
<td class="time" id="i_537300"><a href="/evergreen/2023-10-31#i_537300">11:41</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">hm well.. the router ACLs could be done w/o wildcards. e.g. ~opensrf:router:private.localhost:router-01</td>
</tr>
<tr id="id_l89" class="cont nick nick_berick dark">
<td class="time" id="i_537301"><a href="/evergreen/2023-10-31#i_537301">11:41</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">if we're at the level of specifying specific routers, there's not really any need for the wildcard</td>
</tr>
<tr id="id_l90" class="new nick nick_eeevil">
<td class="time" id="i_537302"><a href="/evergreen/2023-10-31#i_537302">11:46</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">not sure I follow. from the client's perspective, we need 3 bits of info to make a request: 1) service name 2) my local domain 3) the router "prefix" (this is least needed, but will eventually allow us to go routerless, I believe, even with cross-domain HA/LB)</td>
</tr>
<tr id="id_l91" class="cont nick nick_eeevil">
<td class="time" id="i_537303"><a href="/evergreen/2023-10-31#i_537303">11:47</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">we already specify those things in opensrf_core.xml (concretely)</td>
</tr>
<tr id="id_l92" class="cont nick nick_eeevil">
<td class="time" id="i_537304"><a href="/evergreen/2023-10-31#i_537304">11:48</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">the router prefix is //config/opensrf/router_name</td>
</tr>
<tr id="id_l93" class="cont nick nick_eeevil">
<td class="time" id="i_537305"><a href="/evergreen/2023-10-31#i_537305">11:53</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">put another way, imagine translating from an XMPP jid to a redis queue name. jid structure is $router_name@$local_domain/$service_name, and the equiv redis queue might be $router_name:$service_name:$local_domain and the ACL could allow $client_user_name to write to $router_name:* queues</td>
</tr>
<tr id="id_l94" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537306"><a href="/evergreen/2023-10-31#i_537306">11:54</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Stompro: Your latest commit in the collab branch makes a huge difference. After 45 or so minutes, the output is where it was at 2 days before.</td>
</tr>
<tr id="id_l95" class="new nick nick_Stompro">
<td class="time" id="i_537307"><a href="/evergreen/2023-10-31#i_537307">11:56</a></td>
<td style="color: #00acc7" class="nick">Stompro</td>
<td class="msg ">Great, you probably have much larger @orgs, @shelves, @prefix arrays, the grep lookups were probably taking a long time.</td>
</tr>
<tr id="id_l96" class="new nick nick_eeevil dark">
<td class="time" id="i_537308"><a href="/evergreen/2023-10-31#i_537308">11:57</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">for non-trivial setups, the redis user and ACL file will be machine-generated (for us, at least, and I hope for others to avoid human error at the config file level), so I'm really not personally concerned about the contents being big or messy. but(!) trivial setups, it's still extremely simple, the router_name will be "router" and the ACL will be "opensrf can write to router:*"</td>
</tr>
<tr id="id_l97" class="new nick nick_Dyrcona">
<td class="time" id="i_537309"><a href="/evergreen/2023-10-31#i_537309">11:57</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Stompro: Yeah. I'll have to count some of those after lunch.</td>
</tr>
<tr id="id_l98" class="new nick nick_berick dark">
<td class="time" id="i_537310"><a href="/evergreen/2023-10-31#i_537310">12:04</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: what you're describing would almost certainly work. my thought behing e.g. opensrf:router:private.localhost:router-01 is mainly to limit the amount of changes needed to support the use case and seems equally as machine-generatable.</td>
</tr>
<tr id="id_l99" class="new nick nick_eeevil">
<td class="time" id="i_537311"><a href="/evergreen/2023-10-31#i_537311">12:10</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">what's router-01 in this case (IOW, why don't we just have The User Name for an EG instance's routers)? each domain will just have one router, right? so just having it be '$router:$local_domain:$service' (or '$router:$service:$local_domain') where $router might be literally "router" for dev systems.</td>
</tr>
<tr id="id_l100" class="cont nick nick_eeevil">
<td class="time" id="i_537312"><a href="/evergreen/2023-10-31#i_537312">12:12</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I mean, if having a global prefix of 'opensrf:' in front of every queue has a benefit, +1. to me that seems like noise we don't need, but I can't fight too hard against namespacing "all of opensrf" into "opensrf:" either.</td>
</tr>
<tr id="id_l101" class="new nick nick_berick dark">
<td class="time" id="i_537313"><a href="/evergreen/2023-10-31#i_537313">12:13</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: router-01 in this example is the router's username. but wait, "each domain will just have one router, right?" -- i thought the point of this convo was that you needed multiple routers per domain (to avoid dns hassle, etc.).</td>
</tr>
<tr id="id_l102" class="new nick nick_eeevil">
<td class="time" id="i_537314"><a href="/evergreen/2023-10-31#i_537314">12:14</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">setting aside an opensrf redis namespace prefix (if that's what it really is), what I'm looking for is the ability to have a set of redis queues that follow a patter that clients and services can construct in a known way, and /definitely/ segregates one instances' queues from all others that might happen to live inside the same redis instance</td>
</tr>
<tr id="id_l103" class="cont nick nick_eeevil">
<td class="time" id="i_537315"><a href="/evergreen/2023-10-31#i_537315">12:15</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">we're def talking past each other to some degree :)</td>
</tr>
<tr id="id_l104" class="cont nick nick_eeevil">
<td class="time" id="i_537316"><a href="/evergreen/2023-10-31#i_537316">12:23</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">so each /EG instance/ will have exactly 1 router per redis (xmpp) listening hostname. (we actually have 4 domain types, not just public and private). if the router+service queue (xmpp jid for incoming requests) has a pattern like this: "library_A_router_name:open-ils.cat:public.domain.name" (though "library_A_router_name" woulnd't be guessable like that) then we can make ACLs for the redis user called "library_A_client" such that it can put messages</td>
</tr>
<tr id="id_l105" class="cont nick nick_eeevil">
<td class="time" id="i_537317"><a href="/evergreen/2023-10-31#i_537317">12:23</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">onto the queues that match "library_A_router_name:*", and services can put messages on queues that match "library_A_client:*". the router-to-service pattern is similarly simple, and from the router's perspective can just be based where it got registrations from.</td>
</tr>
<tr id="id_l106" class="cont nick nick_eeevil">
<td class="time" id="i_537318"><a href="/evergreen/2023-10-31#i_537318">12:30</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">(longer term, I believe we can get to routerless with this pattern of "$purpose_user_name:$access_domain:$purpose_marker" for queues. purpose_user_name inlcudes what opensrf_core.xml calls, router_name, and username for services and clients; access_domain is, essentially, public, private, etc (mapping from the actual-dns multi-domain stuff from xmpp and being how we say "I live here (usually private), but I will answer also answer requests over</td>
</tr>
<tr id="id_l107" class="cont nick nick_eeevil">
<td class="time" id="i_537319"><a href="/evergreen/2023-10-31#i_537319">12:30</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">there (usually public). and, purpose_marker is "open-ils.cat" or "router" (where services send registrations, because recall that's a pseudo-service!) or "client:$host:$pid" for response-collection queues)</td>
</tr>
<tr id="id_l108" class="new nick nick_berick dark">
<td class="time" id="i_537320"><a href="/evergreen/2023-10-31#i_537320">12:31</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: in your setup, will you have e.g. 2 instances of open-ils.actor listeners running on one domain, where each receives requests via a different router?</td>
</tr>
<tr id="id_l109" class="new nick nick_eeevil">
<td class="time" id="i_537321"><a href="/evergreen/2023-10-31#i_537321">12:32</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">and for each group of "purpose_user_name" that is also a redis user, the ACLs allow their EG-instance peers to talk at them, as appropriate</td>
</tr>
<tr id="id_l110" class="new special dark">
<td class="time" id="i_537322"><a href="/evergreen/2023-10-31#i_537322">12:33</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">jihpringle joined #evergreen</td>
</tr>
<tr id="id_l111" class="new nick nick_eeevil">
<td class="time" id="i_537323"><a href="/evergreen/2023-10-31#i_537323">12:35</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">berick: if you mean 2 instances of open-ils.actor /from 2 different Evergreen instances/, then yes, every day and all day long. and they should never get confused. in XMPP world, that's super easy because the user part of the jid is part of the "queue" (aka "message destination"), and we can say "hey, services and routers for library X, your xmpp username is 123abc456. also, clients for library X, your xmpp username is 987xyz654."</td>
</tr>
<tr id="id_l112" class="cont nick nick_eeevil">
<td class="time" id="i_537324"><a href="/evergreen/2023-10-31#i_537324">12:37</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">if we map jid to queue name, and put the router/service username at the front, we can say "user 987bcd654 can write to queues matching 123abc456:*" and have the exact same (better! it's actively protected) separation</td>
</tr>
<tr id="id_l113" class="cont nick nick_eeevil">
<td class="time" id="i_537325"><a href="/evergreen/2023-10-31#i_537325">12:37</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">library Y, with router/service user of kdfskljkl and client user of r8r23823 cannot see or touch library X's data</td>
</tr>
<tr id="id_l114" class="cont nick nick_eeevil">
<td class="time" id="i_537326"><a href="/evergreen/2023-10-31#i_537326">12:44</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">maybe there's a missing assumption here...</td>
</tr>
<tr id="id_l115" class="new nick nick_berick dark">
<td class="time" id="i_537327"><a href="/evergreen/2023-10-31#i_537327">12:45</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">eeevil: well, the code uses domains for segregation. running multiple listeners for separate EG instances on one domain is unexpected.</td>
</tr>
<tr id="id_l116" class="cont nick nick_berick dark">
<td class="time" id="i_537328"><a href="/evergreen/2023-10-31#i_537328">12:46</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">it can work w/ some tweaking and I don't think it will need a full shakedown of the addressses</td>
</tr>
<tr id="id_l117" class="new nick nick_eeevil">
<td class="time" id="i_537329"><a href="/evergreen/2023-10-31#i_537329">12:46</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I do not consider (conceptually) the xmpp or redis server as being special or tied to a specific EG instance, ever. it's just a message passing system, and the topology of that layer should not be prescribed.</td>
</tr>
<tr id="id_l118" class="new nick nick_berick dark">
<td class="time" id="i_537330"><a href="/evergreen/2023-10-31#i_537330">12:47</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">of cousre, Redis can host numerous EG instances, it just assumes that no 2 use the same domain name.</td>
</tr>
<tr id="id_l119" class="new nick nick_eeevil">
<td class="time" id="i_537331"><a href="/evergreen/2023-10-31#i_537331">12:48</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">berick: are you against having the prefix be, literally, the username of the redis user, and just having that default to "opensrf"?</td>
</tr>
<tr id="id_l120" class="cont nick nick_eeevil">
<td class="time" id="i_537332"><a href="/evergreen/2023-10-31#i_537332">12:49</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">ah, well, that's where DNS management comes in, by making the domain a separator rather than the user</td>
</tr>
<tr id="id_l121" class="cont nick nick_eeevil">
<td class="time" id="i_537333"><a href="/evergreen/2023-10-31#i_537333">12:50</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I'm not saying you shouldn't be able to have domains be the separator, if that's what you want to use for your setup. but I /am/ saying that I want the /user/ to be the separator in mine.</td>
</tr>
<tr id="id_l122" class="cont nick nick_eeevil">
<td class="time" id="i_537334"><a href="/evergreen/2023-10-31#i_537334">12:50</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">so, let's just make them both use existing configuration data</td>
</tr>
<tr id="id_l123" class="cont nick nick_eeevil">
<td class="time" id="i_537335"><a href="/evergreen/2023-10-31#i_537335">12:51</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">I'll change my router_name and username elements in opensrf_core, and you can change your domains and manage separation in dns</td>
</tr>
<tr id="id_l124" class="new nick nick_berick dark">
<td class="time" id="i_537336"><a href="/evergreen/2023-10-31#i_537336">12:51</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">ottomh, i'm not against it, i would need to consider the ramifications, but it does mean more code changes, hence my hesitation.</td>
</tr>
<tr id="id_l125" class="cont nick nick_berick dark">
<td class="time" id="i_537337"><a href="/evergreen/2023-10-31#i_537337">12:51</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">well i think we can use router name w/o having to restructure everything</td>
</tr>
<tr id="id_l126" class="new nick nick_eeevil">
<td class="time" id="i_537338"><a href="/evergreen/2023-10-31#i_537338">12:52</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">those are options we have available today with xmpp, and frankly, having hosted the most number of instances and learned the lessons from that, we do kinda need to retain that ability</td>
</tr>
<tr id="id_l127" class="cont nick nick_eeevil">
<td class="time" id="i_537339"><a href="/evergreen/2023-10-31#i_537339">12:53</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">eeevil-- # more curmudgeonliness</td>
</tr>
<tr id="id_l128" class="new nick nick_berick dark">
<td class="time" id="i_537340"><a href="/evergreen/2023-10-31#i_537340">12:55</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">another thing to consider: the code as-is supports hungry-hippo style direct to drone delivery by sharing a well-known service address on a domain. if we ahve multiple services on a domain for different eg instances, that won't work -- they'll gobble each other's requests. surely there's other ways to accommodate it, but i don't want to lose that.</td>
</tr>
<tr id="id_l129" class="new nick nick_eeevil">
<td class="time" id="i_537341"><a href="/evergreen/2023-10-31#i_537341">13:00</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">well, if we put the router/service (let's just simplify for the moment and combine those 2, even though you /could/ have different accounts) at the front, we can /still/ do that. because the client knows how to construct a "router" destination via //config/opensrf/router_name, and the services /can/ know how to listen to that queue via their own name as the prefix. so, maybe a patch, but it can still be handled. that does /not/ get us HA/LB</td>
</tr>
<tr id="id_l130" class="cont nick nick_eeevil">
<td class="time" id="i_537342"><a href="/evergreen/2023-10-31#i_537342">13:00</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">routerless by itself, but it isn't any different than "bare service name" WRT hungry-hungry-hippo routing</td>
</tr>
<tr id="id_l131" class="cont nick nick_eeevil">
<td class="time" id="i_537343"><a href="/evergreen/2023-10-31#i_537343">13:01</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">"slap my/the-routers username on the front" is really no harder than just dumping them message on a hard-coded "opensrf:$whatever" queue</td>
</tr>
<tr id="id_l132" class="cont nick nick_eeevil">
<td class="time" id="i_537344"><a href="/evergreen/2023-10-31#i_537344">13:01</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">s/them/the/</td>
</tr>
<tr id="id_l133" class="cont nick nick_eeevil">
<td class="time" id="i_537345"><a href="/evergreen/2023-10-31#i_537345">13:05</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">meta-question: if a patch for opensrf-on-redis showed up that did what I'm advocating (allow what we can do in xmpp land, default to the string "opensrf" just like opensrf_core.xml does now), will there be much push-back? unless I'm severely misunderstanding both how redis works and what I'm asking for, I'm really only talking about replacing the hard-coded string "opensrf" with the redis user name</td>
</tr>
<tr id="id_l134" class="cont nick nick_eeevil">
<td class="time" id="i_537346"><a href="/evergreen/2023-10-31#i_537346">13:07</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">(that's a meta-question for all interested in opensrf-on-redis, not just berick ;) )</td>
</tr>
<tr id="id_l135" class="new nick nick_berick dark">
<td class="time" id="i_537347"><a href="/evergreen/2023-10-31#i_537347">13:08</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">it's a littl more than that. the routing is more domain based than specific end-point based (for hungry-hippo drones). there's also a bug in the current implemtation i realized during this covo i need to fix.</td>
</tr>
<tr id="id_l136" class="cont nick nick_berick dark">
<td class="time" id="i_537348"><a href="/evergreen/2023-10-31#i_537348">13:09</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">give me a couple days to try and cover the use case? if nothing else it would help me get my brain back into that territory</td>
</tr>
<tr id="id_l137" class="new nick nick_eeevil">
<td class="time" id="i_537349"><a href="/evergreen/2023-10-31#i_537349">13:13</a></td>
<td style="color: #006b95" class="nick">eeevil</td>
<td class="msg ">berick++</td>
</tr>
<tr id="id_l138" class="new nick nick_berick dark">
<td class="time" id="i_537350"><a href="/evergreen/2023-10-31#i_537350">13:14</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">and now afk for a bit cuz mtgs</td>
</tr>
<tr id="id_l139" class="new special">
<td class="time" id="i_537351"><a href="/evergreen/2023-10-31#i_537351">13:15</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">dmoore joined #evergreen</td>
</tr>
<tr id="id_l140" class="cont special">
<td class="time" id="i_537352"><a href="/evergreen/2023-10-31#i_537352">14:30</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">Rogan joined #evergreen</td>
</tr>
<tr id="id_l141" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537353"><a href="/evergreen/2023-10-31#i_537353">14:52</a></td>
<td style="color: #032c28" class="nick">* Dyrcona</td>
<td class="msg act ">suspects marc_export exposes/causes a memory leak in Perl 5.</td>
</tr>
<tr id="id_l142" class="new special">
<td class="time" id="i_537354"><a href="/evergreen/2023-10-31#i_537354">15:37</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">mantis1 left #evergreen</td>
</tr>
<tr id="id_l143" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537355"><a href="/evergreen/2023-10-31#i_537355">15:43</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Stompro: 4.5 hours versus 5+ days. I'll take it!</td>
</tr>
<tr id="id_l144" class="cont nick nick_Dyrcona dark">
<td class="time" id="i_537356"><a href="/evergreen/2023-10-31#i_537356">15:43</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Stompro++</td>
</tr>
<tr id="id_l145" class="new nick nick_Stompro">
<td class="time" id="i_537357"><a href="/evergreen/2023-10-31#i_537357">15:47</a></td>
<td style="color: #00acc7" class="nick">Stompro</td>
<td class="msg ">Dyrcona, that is great to hear. Was that for just one library, or everything?</td>
</tr>
<tr id="id_l146" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537358"><a href="/evergreen/2023-10-31#i_537358">15:52</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">That was more or less everything: a simulation of exporting for Aspen.</td>
</tr>
<tr id="id_l147" class="new nick nick_mmorgan">
<td class="time" id="i_537359"><a href="/evergreen/2023-10-31#i_537359">15:52</a></td>
<td style="color: #00b65f" class="nick">mmorgan</td>
<td class="msg ">Stompro++</td>
</tr>
<tr id="id_l148" class="new nick nick_Stompro dark">
<td class="time" id="i_537360"><a href="/evergreen/2023-10-31#i_537360">15:57</a></td>
<td style="color: #00acc7" class="nick">Stompro</td>
<td class="msg ">Nice, I have a few more speed ups, i'm playing around with threading to see if I can get several processes doing the MARC::Record creation step, since that is where 50% of the time is being taken up... so maybe we can get that down to 2 hours. :-)</td>
</tr>
<tr id="id_l149" class="new nick nick_Dyrcona">
<td class="time" id="i_537361"><a href="/evergreen/2023-10-31#i_537361">15:59</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Stompro: When you say threading do you mean Perl threads or multiple processes? Either way, I want to stop you there. :)</td>
</tr>
<tr id="id_l150" class="new nick nick_Stompro dark">
<td class="time" id="i_537362"><a href="/evergreen/2023-10-31#i_537362">15:59</a></td>
<td style="color: #00acc7" class="nick">Stompro</td>
<td class="msg ">perl threads</td>
</tr>
<tr id="id_l151" class="new nick nick_berick">
<td class="time" id="i_537363"><a href="/evergreen/2023-10-31#i_537363">16:00</a></td>
<td style="color: #3b0069" class="nick">berick</td>
<td class="msg ">heh</td>
</tr>
<tr id="id_l152" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537364"><a href="/evergreen/2023-10-31#i_537364">16:00</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">Perl threads will not work. When Encode gets invoked, and at some point it will, Perl will choke and die.</td>
</tr>
<tr id="id_l153" class="new nick nick_Stompro">
<td class="time" id="i_537365"><a href="/evergreen/2023-10-31#i_537365">16:01</a></td>
<td style="color: #00acc7" class="nick">Stompro</td>
<td class="msg ">Oh, bummer. Thanks for the heads up.</td>
</tr>
<tr id="id_l154" class="new nick nick_Dyrcona dark">
<td class="time" id="i_537366"><a href="/evergreen/2023-10-31#i_537366">16:02</a></td>
<td style="color: #7d008d" class="nick">Dyrcona</td>
<td class="msg ">I updated the bug with a pullrequest tag and "partial" signoff branch. I'm happy at this point. I think you got the big things.</td>
</tr>
<tr id="id_l155" class="new nick nick_Bmagic">
<td class="time" id="i_537367"><a href="/evergreen/2023-10-31#i_537367">16:36</a></td>
<td style="color: #9d6200" class="nick">Bmagic</td>
<td class="msg ">Dyrcona++ Stompro++</td>
</tr>
<tr id="id_l156" class="new special dark">
<td class="time" id="i_537368"><a href="/evergreen/2023-10-31#i_537368">17:20</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">jihpringle joined #evergreen</td>
</tr>
<tr id="id_l157" class="cont special dark">
<td class="time" id="i_537369"><a href="/evergreen/2023-10-31#i_537369">17:21</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">mmorgan left #evergreen</td>
</tr>
<tr id="id_l158" class="cont special dark">
<td class="time" id="i_537370"><a href="/evergreen/2023-10-31#i_537370">19:03</a></td>
<td style="color: #ad7900" class="nick"></td>
<td class="msg ">sandbergja joined #evergreen</td>
</tr>
</table>
</form>
<span id="bottom" />
<p>
<a href="/evergreen/2023-10-30" rel="prev">
← Previous day</a> |
<a href="/">Channels</a> |
<a href="/evergreen/">#evergreen index</a> |
<a href="/evergreen/today">Today</a> |
<a href="/evergreen/2023-11-01" rel="next">
Next day →</a> |
<a href="/evergreen/search">Search</a> |
<a href="http://www.google.com/search?q=site%3Airc.evergreen-ils.org+inurl%3Aevergreen">Google Search</a>
| <a href="/evergreen/2023-10-31/text">Plain-Text</a> |
<a href="/evergreen/2023-10-31/summary">summary</a>
| <a href="https://webchat.freenode.net/?channels=evergreen">Join Webchat</a>
</p>
<div id="footer">
<p>Powered by <a href="http://moritz.faui2k3.org/en/ilbot">ilbot</a>.
<strong>Any questions? Ask bshum in #evergreen on irc.libera.chat</strong></p>
<p>
Evergreen is open source software, freely
licensed under <a href="http://www.gnu.org/licenses/gpl-2.0.html"
target="_blank">GNU GPLv2</a> or later.<br /> The <a
href="http://evergreen-ils.org/blog/?p=583" target="_blank">Evergreen Project is
a member</a> of <a href="http://sfconservancy.org/" target="_blank">Software
Freedom Conservancy</a>.
</p>
</div>
<script type="text/javascript" src="/s/jquery.min.js"></script>
<script type="text/javascript">
IlbotConfig = {
base_url: '/',
channel: 'evergreen',
day: '2023-10-31',
still_today: false
};
</script>
<script type="text/javascript" src="/s/dynamic.js"></script>
</body>
</html>
<!-- -->