On Thu, Dec 4, 2014 at 12:08 PM, George Christman <gchrist...@cardaddy.com> 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 > > > wrote: > > > 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 > > > > > > -- > George Christman > CEO > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York >
