George - sounds like those components might be using session persistence for some of their data (e.g. in the case of Grid it uses @Persist , which defaults to session persistence, to store the GridPaginationModel - e.g. https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Grid.java) . I'm not sure if there is a way to change the default behavior of @Persist (knowing tapestry , there probably is) if you want your app to be totally stateless (or at least not store state in the session) but I'm not entirely sure how much that will buy you in terms of general scalability (other than being able to check the box of "we're not using the servlet session").
I doubt that this would be a scaling issue but certainly something that would be nice if there is a way to know that about a component (before you use it). The Grid javadocs for 5.4 seem to provide an option for that (e.g. http://tapestry.apache.org/5.4/apidocs/org/apache/tapestry5/corelib/components/Grid.html , the defaultPaginationModel parameter) Cheers - Alex K On Thu, Dec 4, 2014 at 8: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. >
