Re: Sticky Sessions
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.
Re: Sticky Sessions
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
Re: Sticky Sessions
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. 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. 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
Re: Sticky Sessions
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
Re: Sticky Sessions
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
Re: Sticky Sessions
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? 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
Re: Sticky Sessions
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
