D
dbeavon
Guest
I'm not totally happy with the behavior of our load-balancing model in PASOE either. I don't intend to hijack your question but I just want to clarify it so I understand better. Does "sticky" sessions simply imply that the load-balancer keeps you on the same server instance (using the cookie or the source-ip)? Or does that imply more "advanced" functionality (... ie. the HTTP session may persisted to shared storage and another independent server instance is able to continue servicing the same HTTP session). My understanding is that one of the load-balancing models ("tomcat load balancing") is able to provide more "advanced" functionality. see knowledgebase.progress.com/.../how-to-configure-pasoe-for-load-balancing I think HTTP sessions are (theoretically) able survive a fail-over to another server instance - because there is some type of shared storage that is used under-the-hood. I'm not 100% certain about this, but that is what I've gathered. But the other load-balancing models will certainly not allow sessions to survive a fail-over from one instance to another because the instances are totally independent and have no knowledge of one another. So in your question, which load-balancing model are you referring to (per that KB)? The identification of the load-balancer seems relevant, right? Thanks, David PS. (Final question, I'm not familiar with the "highly available redis cluster"... is that another way of allowing server instances to provide "advanced" functionality whereby sessions can survive a fail-over from one server to another? Is it some type of shared storage? )
Continue reading...
Continue reading...