Evergreen ILS Website

IRC log for #evergreen, 2021-12-01

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:09 eglogbot joined #evergreen
00:09 Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged.
06:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:11 rjackson_isl_hom joined #evergreen
07:17 rjackson_isl_hom joined #evergreen
08:24 rfrasur joined #evergreen
08:35 mmorgan joined #evergreen
08:40 collum joined #evergreen
08:49 rfrasur gmcharlt, I am watching your Vu-Find presentation...and am enthralled.  Not so much by the discovery layer (that too), but all the other stuff you're talking about.
08:50 rfrasur s/Vu-Find/VuFind
08:55 jvwoolf joined #evergreen
09:06 Dyrcona joined #evergreen
09:32 mantis joined #evergreen
11:00 jeff ansible++ yaml--
11:02 jeff (but really, I'd probably not want to be writing playbooks and roles in JSON either)
11:18 collum joined #evergreen
11:25 Dyrcona Yeah, YAML is a mess, just like everything else we use regularly.
11:27 berick huh, i like yaml, at least for config files.  agreed playbooks are another story.
11:29 Dyrcona People who say they like YAML have never tried to implement a parser for YAML. :)
11:32 berick why on earth would I do that? ;)
12:28 jeff given a "brick" with a head running a router and one or more additional brick members running services (but no router), it's important to have cross-machine XMPP communication. are there scenarios where cross-brick XMPP communication comes into play?
12:28 jeff this can probably filed under "things I never learned or have forgotten, and am surprised to find myself asking now"
12:28 jeff s/filed/be filed/
12:32 jeff I can think of scenarios (say, involving an OpenSRF CONNECT / stateful pcrud) where it would be important to have subsequent http requests hit the same brick head if there's no cross-brick communication (and I don't *think* there is, typically?). I think in the past I've seen that addressed with hash-based client-to-backend mapping, or some other "sticky" setting on the load balancer
12:33 jihpringle joined #evergreen
12:33 jeff and with websockets, the long-open connection addresses some of that already. I'd expect there might be some cases where a client talking http to one brick head and websockets to another brick head could create confusion, but then again maybe nothing mixes http and websockets traffic on a single stateful OpenSRF transaction.
12:34 collum joined #evergreen
12:35 Dyrcona jeff: I've considered the cross-brick XMPP but never implemented. I know it works because tsbere did it a few years ago.
12:36 Dyrcona I'm not sure what you're going on about, but I've never had issues using Evergreen as-is with multiple bricks that don't communicate with each other.
12:38 jeff It's quite possible that I'm imagining an issue that doesn't exist, or exists so rarely as to go unnoticed.
12:39 jeff Dyrcona: do you have an environment where two different http requests at two different times from the same client to the same load balancer / frontend proxy can be routed to two different backend servers?
12:44 berick jeff: it happens.  mostly with old dojo UI's using http-translator.  if a client is mid-transaction and is disconnect for a keepalive timeout, it can end up sending follow-up requests that are routed to a different brick (head).
12:45 berick brick head 2 then has to route the mid-transaction request to the drone on brick1 that is handling the transaction
12:46 jeff yep, and we ran into that long-ago with an old ejabberd s2s "route subdomains" setting that needed to be adjusted. I was trying to remember if the communication in that case traversed bricks...
12:46 berick but yeah I think most load balancers avoid this by default by keeping clients pinned to the same brick head
12:46 berick though it can also happen if you take one of the brick heads out of rotation, while leaving its drones active
12:47 jeff I'm pretty sure that recent ejabberd has done away with the setting in question, but I'm not sure if there are other s2s challenges.
12:47 jeff Ah, that would do it also. Good example.
12:47 collum joined #evergreen
13:02 jeffdavis we're looking at cross-server registration, in a meeting ATM though so can't say much
13:59 jeffdavis OK. We were looking at cross-server registration to mitigate the effects of sudden large drone spikes on a single server due to parallel-requests bugs in the client.
13:59 jeffdavis i.e. if some action in the client generates 300 simultaneous pcrud requests, in our current setup they'll all go to the same server, which then runs out of available children. If we can spread requests across multiple servers then we're less likely to hit max_children.
14:00 Dyrcona Or, just fix the code so the 300 requests don't happen.
14:01 * Dyrcona disappears in a fog of headache.
14:01 jeffdavis I mean, yeah, but after more than a year of playing whack-a-mole with those bugs, we need other mitigations.
14:02 jvwoolf1 joined #evergreen
14:02 jeffdavis I know we originally had servers cross-registered and changed things to not be like that a number of years ago, though I no longer remember what issues we were seeing that led to that change.
14:30 jihpringle joined #evergreen
16:39 rjackson_isl_hom joined #evergreen
17:02 mmorgan left #evergreen
18:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
19:13 pinesol [evergreen|gmontimantis] Docs: update lsa-barcode-completion - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5c3f61c>
19:13 pinesol [evergreen|Jane Sandberg] Docs: remove outdated screenshots - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=b0a744e>

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat