I have a URL persist I wrote to solve this problem. It moves the grids data from the session into URL parameters.
I'll post the code later today On Thursday, December 4, 2014, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote: > On Thu, Dec 4, 2014 at 12:08 PM, George Christman <gchrist...@cardaddy.com > <javascript:;>> > wrote: > > > I'd have to say 98% of my app is stateless, I only have a few admin pages > > that still use tapestry grid. Other than that Captcha and Tapestry > Security > > redirect seem to be the only two items effected by this, so I don't think > > I'll have a memory issue. > > > > Yeah, that's how it should be. > > > > Kalle, I still use AWS and thus far it's been very reasonable. I just > worry > > instances being held active and running my bill up because of sticky > > sessions. I'll admit, I'm no expert in this, so perhaps my understanding > > isn't correct. > > Is there any recommendation for the timeout? I currently have it set at > 0. > > > > That's your issue then, you want to set it to a positive number to let them > expire. From the servlet spec: "If the timeout is 0 or less, the container > ensures the default behavior of sessions is never to time out." Personally, > I'm advocating use of short session expiration (in the order of 1-5 mins), > then extending it via async calls (as described in > http://tynamo.org/tapestry-conversations+guide). At least tomcat has a > default expiration of 30 mins, I'm not sure if the spec ever said anything > about it. > > Kalle > > > > > On Thu, Dec 4, 2014 at 1:26 PM, Kalle Korhonen < > kalle.o.korho...@gmail.com <javascript:;> > > > > > wrote: > > > > > On Thu, Dec 4, 2014 at 5:54 AM, George Christman < > > gchrist...@cardaddy.com <javascript:;>> > > > 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 > > > > > > > > > > > -- > > George Christman > > CEO > > www.CarDaddy.com > > P.O. Box 735 > > Johnstown, New York > > >
