4 ms·

I don't think you need to pass closures between machines but you do need to use "sticky sessions" so that your load balancers deliver all requests for a particu

I don't think you need to pass closures between machines but you do need to use "sticky sessions" so that your load balancers deliver all requests for a particular session back to the same app instance. I haven't seen much discussion of sticky sessions in quite a while as 12-factor apps built around stateless processes have no need for them and that has been the dominant paradigm for quite a while.

muxator 7y ago
An application requiring sticky session sounds like an architecture smell to me. It works, and you can get a long way with it, but a system that relies on requests always being served by the same server sounds a bad idea to me. What if that server breaks/need a security update/has to be rebooted? For security updates & restarts you can always use session draining, but then your operativity becomes dependent on an upstream service (a LB?), which in a large organization is probably handled by another team, and you end up needing to coordinate and complicate something that could have been simple. As long as it's a conscious choice, it's ok not baking in tolerance for these failure modes, but personally I would only accept it for POCs/prototypes.
- deckard1 7y ago
  Yeah, I don't see how this type of architecture pays off in the end. You're opening yourself up to long-running continuations that provide a DoS memory attack vector, put pressure on the GC, and you still have to figure out when to actually GC. Imagine a shopping cart continuation hanging out for days or even weeks, waiting on the user to click the order button. Now imagine thousands of these. And for what? Just so you can run some logic on the server? Which you really shouldn't be doing in the first place. And who is the lucky person that has to deal with server affinity? Seems like the developer is just tossing his work over the fence to some poor dev ops guy to clean up.
- soegaard 7y ago
  These are serious concerns. An attempt to make web programming with continuations work without requiring sticky sessions is "Stateless Servlets": https://docs.racket-lang.org/web-server/stateless.html?q=stateless#%28part._considerations%29 https://docs.racket-lang.org/web-server/stateless.html?q=sta... A stateless servlets makes it possible to serialize continuations and store them on the client/database/disk. There is no such thing as a free lunch, so that approach has pros and cons too.

muxator 7y ago

An application requiring sticky session sounds like an architecture smell to me. It works, and you can get a long way with it, but a system that relies on requests always being served by the same server sounds a bad idea to me. What if that server breaks/need a security update/has to be rebooted? For security updates & restarts you can always use session draining, but then your operativity becomes dependent on an upstream service (a LB?), which in a large organization is probably handled by another team, and you end up needing to coordinate and complicate something that could have been simple. As long as it's a conscious choice, it's ok not baking in tolerance for these failure modes, but personally I would only accept it for POCs/prototypes.

deckard1 7y ago
Yeah, I don't see how this type of architecture pays off in the end. You're opening yourself up to long-running continuations that provide a DoS memory attack vector, put pressure on the GC, and you still have to figure out when to actually GC. Imagine a shopping cart continuation hanging out for days or even weeks, waiting on the user to click the order button. Now imagine thousands of these. And for what? Just so you can run some logic on the server? Which you really shouldn't be doing in the first place. And who is the lucky person that has to deal with server affinity? Seems like the developer is just tossing his work over the fence to some poor dev ops guy to clean up.
soegaard 7y ago
These are serious concerns. An attempt to make web programming with continuations work without requiring sticky sessions is "Stateless Servlets": https://docs.racket-lang.org/web-server/stateless.html?q=stateless#%28part._considerations%29 https://docs.racket-lang.org/web-server/stateless.html?q=sta... A stateless servlets makes it possible to serialize continuations and store them on the client/database/disk. There is no such thing as a free lunch, so that approach has pros and cons too.