Do I need AWS sticky sessions?

Joe Barnes

unread,

Mar 12, 2014, 10:08:40 AM3/12/14

to lif...@googlegroups.com

I'm deploying a Lift application on AWS Elastic Beanstalk, and I'm referencing Richard Dallaway's Lift Cookbook to help me get it right the first time. In there I see that I need "Session Stickiness" if I'm utilizing any of Lift's "state features"... While I think that means SessionVars, etc, I'd like to know if anyone can clarify what Richard meant by "state features". Any tips are appreciated. Thanks!

Joe

Diego Medina

unread,

Mar 12, 2014, 10:29:42 AM3/12/14

to Lift

if you use any call to SHtml.*, you are using state, because it means that lift is keeping a list/map of function ids => functions in memory, and if your user goes to server1, but clicking a button takes him/her to server2, server2 will not have that functionId in memory

hope it helps

Diego

On Wed, Mar 12, 2014 at 10:08 AM, Joe Barnes <barn...@gmail.com> wrote:

I'm deploying a Lift application on AWS Elastic Beanstalk, and I'm referencing Richard Dallaway's Lift Cookbook to help me get it right the first time. In there I see that I need "Session Stickiness" if I'm utilizing any of Lift's "state features"... While I think that means SessionVars, etc, I'd like to know if anyone can clarify what Richard meant by "state features". Any tips are appreciated. Thanks!

Joe

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala consultant
di...@fmpwizard.com
http://fmpwizard.telegr.am

Richard Dallaway

unread,

Mar 12, 2014, 10:30:21 AM3/12/14

to Lift, Lift

Yeah, I didn’t define it very well, partly because it’s a slippery concept. For a better discussion, see Simply Lift: http://simply.liftweb.net/index-Chapter-20.html

I was thinking about something local in the memory to one machine (or instance, or cell, or whatever terminology is used) that you don’t want to (or can’t) recreate on a request in the short term. So a SessionVar would usually count, as would comet and ajax and the SHtml.* methods you give a function too one way or another. I’m not aware of an exhaustive list.

For example, if I had a SessionVar[Box[Basket]] and I was running my application across > 1 machines, I’d want to use sticky session. Likewise, if I’m rendering links using a.link(“Click me”, () => thingClicked()), I’d need to use sticky sessions.

Except :-) … if my SessionVar had a default that allowed it to recover state reliably, then I might not care. E.g., SessionVar[Box[basket](myRecoverFromDatabaseFunction).

BTW, AWS changes from time to time, so if the cookbook is out of date, feel free to send a pull request. https://github.com/d6y/lift-cookbook/blob/master/11-Deployment.asciidoc (wow, when did GitHub start rendering Asciidoc so well?)

Richard

On 12 Mar 2014 14:08:40, Joe Barnes <barn...@gmail.com> wrote:

I'm deploying a Lift application on AWS Elastic Beanstalk, and I'm referencing Richard Dallaway's Lift Cookbook to help me get it right the first time. In there I see that I need "Session Stickiness" if I'm utilizing any of Lift's "state features"... While I think that means SessionVars, etc, I'd like to know if anyone can clarify what Richard meant by "state features". Any tips are appreciated. Thanks!

Joe

Joe Barnes

unread,

Mar 12, 2014, 10:45:14 AM3/12/14

to lif...@googlegroups.com

Thanks Richard and Diego. We're utilizing a SessionVar which currently cannot cleanly recover from the DB as well as some comet, so I'm going to enable stickiness.

Joe

You received this message because you are subscribed to a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/M-0DNnuae4w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

twitter: @joescii

github: barnesjd

blog: proseand.co.nz

Joe Barnes

unread,

Mar 12, 2014, 11:21:37 AM3/12/14

to lif...@googlegroups.com

After closer inspection, we found that there are two options for stickiness. One is the default mentioned in the book, which is the setting in the Elastic Beanstalk Load Balancer configuration. Here you give a timeout for the session cookie, and AWS generates its own cookie for tracking the session. The other option for stickiness is available in the EC2 Load Balancer settings (click here and see "Application-Controlled Session Stickiness"). You can give AWS the name of your own session cookie, which it will then use to track the sessions. This seems like a better option since it will be in sync with our own session handling.

That being said, what is the name of the cookie? I see one named "JSESSIONID". Given it's the only one, is this safe for me to use?

Thanks again,

Joe

On Wednesday, 12 March 2014 09:45:14 UTC-5, Joe Barnes wrote:

Thanks Richard and Diego. We're utilizing a SessionVar which currently cannot cleanly recover from the DB as well as some comet, so I'm going to enable stickiness.

Joe

On Wed, Mar 12, 2014 at 9:30 AM, Richard Dallaway <ric...@dallaway.com> wrote:

Yeah, I didn’t define it very well, partly because it’s a slippery concept. For a better discussion, see Simply Lift: http://simply.liftweb.net/index-Chapter-20.html

I was thinking about something local in the memory to one machine (or instance, or cell, or whatever terminology is used) that you don’t want to (or can’t) recreate on a request in the short term. So a SessionVar would usually count, as would comet and ajax and the SHtml.* methods you give a function too one way or another. I’m not aware of an exhaustive list.

For example, if I had a SessionVar[Box[Basket]] and I was running my application across > 1 machines, I’d want to use sticky session. Likewise, if I’m rendering links using a.link(“Click me”, () => thingClicked()), I’d need to use sticky sessions.

Except :-) … if my SessionVar had a default that allowed it to recover state reliably, then I might not care. E.g., SessionVar[Box[basket](myRecoverFromDatabaseFunction).

BTW, AWS changes from time to time, so if the cookbook is out of date, feel free to send a pull request. https://github.com/d6y/lift-cookbook/blob/master/11-Deployment.asciidoc (wow, when did GitHub start rendering Asciidoc so well?)

Richard

On 12 Mar 2014 14:08:40, Joe Barnes <barn...@gmail.com> wrote:

I'm deploying a Lift application on AWS Elastic Beanstalk, and I'm referencing Richard Dallaway's Lift Cookbook to help me get it right the first time. In there I see that I need "Session Stickiness" if I'm utilizing any of Lift's "state features"... While I think that means SessionVars, etc, I'd like to know if anyone can clarify what Richard meant by "state features". Any tips are appreciated. Thanks!

Joe

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/M-0DNnuae4w/unsubscribe.

To unsubscribe from this group and all its topics, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Viktor Hedefalk

unread,

Mar 12, 2014, 11:28:30 AM3/12/14

to liftweb

JSESSIONID is the standard cookiename used by the servlet api:

http://download.oracle.com/otn-pub/jcp/servlet-3_1-fr-eval-spec/servlet-3_1-final.pdf?AuthParam=1394638158_23874234c9f100bafa5049e3cc9facd8

That's most definitely what you want.

Cheers,

Viktor

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

Joe Barnes

unread,

Mar 12, 2014, 11:29:18 AM3/12/14

to lif...@googlegroups.com

Awesome, thanks Viktor!

To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Diego Medina

unread,

Mar 12, 2014, 11:38:05 AM3/12/14

to Lift

yes, that is the session cookie name

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Joe Barnes

unread,

Mar 12, 2014, 12:57:04 PM3/12/14

to lif...@googlegroups.com

Well, it turns out that the application-controlled session stickiness has to be configured in EC2, which gets clobbered any time you make Load Balancer changes in the Elastic Beanstalk configuration console. That's just begging to get screwed up. I've posted a stackoverflow question about this, since it has to do with AWS rather than Lift. In the meantime, we'll let AWS have it's own cookie for the session bookkeeping.

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/M-0DNnuae4w/unsubscribe.

To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
twitter: @joescii
github: barnesjd
blog: proseand.co.nz

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Antonio Salazar Cardozo

unread,

Mar 14, 2014, 2:51:08 PM3/14/14

to lif...@googlegroups.com

For what it's worth, when I've implemented session stickiness in the past I've let the proxy (haproxy) or server (nginx) manage its own server/session mapping. It is admittedly a bit less efficient, but cleaner until the efficiency becomes a problem.