3 ms·

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 reque

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.

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.