Re: Sticky Sessions
On Thu, Dec 4, 2014 at 4:43 PM, George Christman
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 >
> 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
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
wrote:
> On Thu, Dec 4, 2014 at 12:08 PM, George Christman >
> 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
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
wrote:
> On Thu, Dec 4, 2014 at 12:08 PM, George Christman >
> 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
On Thu, Dec 4, 2014 at 12:08 PM, George Christman
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 >
> 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'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
wrote:
> On Thu, Dec 4, 2014 at 5:54 AM, George Christman
> 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 5:54 AM, George Christman
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
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 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. >
Sticky Sessions
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.
