| 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> |
