On Thu, Dec 4, 2014 at 5:54 AM, George Christman <gchrist...@cardaddy.com>
wrote:
> Hi guys, so I've had a slew of strange behaviors over the past few months
> with a few different Tapestry components such as Tapestry Grid, Tapestry
> Captcha, and writting/removing cookies. Last night I was finally able to
> fix them, but at the cost of a sticky session. My application sits behind a
> load balancer, so my question is why do I need to use a sticky session and
> how do I avoid the use of them? I'm concerned with the fact this is going
> to cause a scaling dilemma.
>
I'd almost say that sticky sessions are more the norm than the exception
for Java web applications. Unless you change your implementation, you have
a choice between sticky sessions or replicated/centeralized sessions.
Sessions in your cluster are probably not managed by memcached or some such
(which is another single point of failure), causing the strange behavior.
Furthermore, I see neither session usage nor sticky sessions as inherently
bad. Memory is cheap although in today's cloud managed solutions using
memory may end up costing extra to you. It depends on how your load
balancer works and whether the bottleneck in a typical usage pattern is cpu
or memory. Even if your load balancer does a simple random choice but
memory doesn't cost you, you are most likely fine with sticky sessions. If
additional servers cost you, but you can do dynamic horizontal scaling with
cpu/memory thresholds to spawn new instances, then sticky sessions are
actually desirable.
Kalle
PS. @Alex - yes, can configure default persistence strategy with
@Meta("tapestry.persistence-strategy=client") per page - but that only
works if the components don't require an explicit persistence strategy
