I get the rationale behind that, and how the documentation can be read to mean that, but for some mysterious reason I’m yet to come across something that confirms, for example, that the database query feeding the assigns is run a second time, so I’m having a rough time accepting that the two runs are identical.
There’s another oddity involved as well. By the code the JS on the client appears to be sending the HTTP request it intends to upgrade to a web-socket to the /live route which is indeed defined in endpoint.ex. The logs I have set up at the moment never shows that path being accessed, but it might not be looking in the right places to see that.
It would explain a lot if the /live endpoint operates largely independently, takes all the detail it needs from the url/cookie sent by the LV JS code to eventually result in the web socket connecting to process where the state data for the session is kept, but that does not seem to be the explanation I’m getting here.
By your understanding and the interpretation of the code and documentation this double and identical execution of mount/2 would result in all the setup work including the requisite database queries being done twice (which I truly think I’d have picked up by now), but the code reveals that mount/2 has two heads, the first of which matches on a param called “token” being set, which strongly suggests that being the version that gets called when liveview sets up the web socket while the other head matches the regular code involving loading the assigns from the database etc.
Meaning that though mount/2 most likely is getting called twice, the two calls do entirely different things (and thus) share nothing (that isn’t contained in the token, url and cookie values) and need not run on the same node).
I (naturally) lose track of the implied consequences of the token-matching mount/2 calling push_navigate with its (potentially updated) socket parameter, particularly if that contains an opportunity for the second process/pod/pid handling the web-socket setup to somehow locate the process/pod/pid the other mount/2 ran in and where the session has its state in memory. I’d still want and need to understand how that happens, but if that is the net result it would be a solid starting point.
At the moment the evidence I see supports the notion that somehow the process which responded to the original HTTP request (and ran the second version of mount/2) ends up reading and writing to the web-socket in the context of the state it keeps in memory relating to the session.
In principle I also favour of explicit coding as opposed to magic things happening but I’m not a stickler for it and can appreciate a well managed bit of magic doing wonders for me. It’s just in this particular case where I’m forced by circumstance to learn exactly how LiveView and it’s web-socket actually works as starting point for matching the behaviour I see to the load balancer rules I am looking to assert control over.
It’s critically important because of the gap between bare metal kubernetes and hosted kubernetes which are identical and compatible in most respects except for load balancing. Cloud providers typically offer their own load balancing that’s fully integrated into their kubernetes products while on bare metal you’re on your own with half-solutions like MetalLB, Ingress-controllers doubling as load balancers themselves and a whole spectrum of CNIs getting involved as well.
My aim has always been and remains to retain portability between cloud hosted and bare-metal deployments of my appication to keep all my options open as I deal with varying growth rates. In that context my current mission is to come up with a load balancer solution for bare metal that mimics enough of the capabilities of the cloud provider’s load balancers for my needs. I’ve managed (largely) to do that using HAProxy external to the cluster and now it’s down to defining the right rules for it that get the job done but for which there also is a clear mapping to the rules I can define in (each of) the cloud providers’ load balancers. I’ve not sought to or managed to make it “plug-compatible” with the cloud-based versions, firstly because it’s beyond my abilities to mess around with kubernetes at the API level to automate LB-IPAM provisioning and secondly because I’m given to the the notion that everything should be made as imple as possible, and no simpler.
I was planning on writing down my current understanding of exactly what happens and ask for affirmation, refutal or correction of each individual step/statement. As soon as I am able to write those down without needing conditional statements and disclaimers, I’ll surely do that, but I’m not there yet.
Thank you for your efforts to so far, and pretty please for what lies ahead. You guys are awesome.
