On Thu, Dec 4, 2014 at 4:43 PM, George Christman <gchrist...@cardaddy.com> wrote:
> Well before I had it disabled with the load balancer which was causing the > issues. It seemed to fix things when I activated it, but it had a default > time of 0. I'll change it to 5mins for now and if I didn't etend it via > async, what would happen? > You mean what happens when a server side session expires? Same as if it was invalidated, i.e. "void *invalidate <https://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpSession.html#invalidate%28%29>* () Invalidates this session then unbinds any objects bound to it." Kalle > > On Thu, Dec 4, 2014 at 3:41 PM, Kalle Korhonen <kalle.o.korho...@gmail.com > > > wrote: > > > 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 > > > > > > > > > -- > George Christman > CEO > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York >
