Looking for shared session solution for using Lucee in cloud environment

1,220 views
Skip to first unread message

Siegfried Wagner

unread,
Feb 18, 2015, 11:39:30 AM2/18/15
to lu...@googlegroups.com
Hi,

as I noticed here are already quite some people already using Lucee with cloud setups, so you probably also faced (and solved) the problem of how to share sessions between Lucee instances.
As far as I found out it seems that there is more than one single solution to this. What is the best way to set this up (e.g. in Amazon AWS)?

I'm relatively new to Railo and Lucee, but I try to keep up as quick as possible (and I'm working with a lot of people that understand very much about it!).
So any help is appreciated.

Thanks a lot!
Siegfried

Gert Franz

unread,
Feb 18, 2015, 12:11:26 PM2/18/15
to lu...@googlegroups.com

The easiest way to do it is to set the storage flag for one datasource and set the sessionstorage to the datasource you just enabled.

 

In addition if you so not use sticky sessions, just add the param sessioncluster to true. Like this (Application.cfc)

 

{

            this.sessionstorage = 'yourdatasource';

            this.sessioncluster = true;

}

 

If you use the Application.cfm instead, you do it like this:

 

<cfapplication name="yourapplicationname" sessionstorage="yourdatasource" sessioncluster="#true#">

 

Or

 

<cfapplication action="update" sessionstorage="yourdatasource" sessioncluster="#true#">

 

HTH

 

Sincerely
Gert Franz

 

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: ge...@rasia.ch
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/73dadad6-49ec-4135-8e56-55be85c127a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

image001.png

Michael van Leest

unread,
Feb 18, 2015, 1:45:41 PM2/18/15
to lu...@googlegroups.com
My current setup is: 

- elastic load balancer 
- x amount of T2.small web servers (Lucee) and auto scaling 
- ElastiCache cluster as the session storage (with the memcache plugin installed).

A quick note at ElastiCache is that it CANT be used from outside AWS. So testing sessioncluster locally will fail (this bit me before).

If the load is not a issue and your db server, than using the db for sessions will be fine. I choose for ElastiCache for sessions to add auto scaling later.

Hope this helps,

Michael

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


--
Sent from Gmail Mobile

Brad Wood

unread,
Feb 18, 2015, 5:24:04 PM2/18/15
to lu...@googlegroups.com
I'll add, Ortus has a commercial Couchbase extension for Railo that can store sessions externally on a distributed cluster.  We haven't updated it yet for Lucee, but you can let me know if you're interested.

Thanks!

~Brad

Nando Breiter

unread,
Feb 18, 2015, 5:37:08 PM2/18/15
to lu...@googlegroups.com
The easiest way to avoid the need for a shared sessions (that I've heard of) is to use Nginx as your web server / load balancer. Within the upstream directive of the web server used as load balancer, simply set the ip_hash directive, and this will ensure that the same instance of Lucee is always used for a given client, obviating the need for shared sessions.



Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

Igal @ Lucee.org

unread,
Feb 18, 2015, 5:45:54 PM2/18/15
to lu...@googlegroups.com
while this is a pretty good solution, which I employ myself on my servers, it is not optimal. 

nginx plus, which is a paid product, offers a session affinity load balancing solution, which is cookie based as opposed to ip-based.

either of those solutions fail if one of your backend servers fails, though.

an external data store solution would be more robust, but at the expense of (de)serializing the session data.

we have a few plans to improve it in Lucee in the future though.

Igal Sapir
Lucee Core Developer
Lucee.org

Michael van Leest

unread,
Feb 18, 2015, 5:47:23 PM2/18/15
to lu...@googlegroups.com
@nando: that is one way of doing it, but if a instance fails, the session is lost. Also if you deploy a lot of code daily and sometimes destroy the servers and create new ones with modified setup, it gives the same issue that sessions will be lost. 

The ElastiCache option was therefor selected as a easy solution for session persistence across all servers.

Mike

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

Geoff Parkhurst

unread,
Feb 18, 2015, 6:02:18 PM2/18/15
to lu...@googlegroups.com
Anyone tackling onSessionEnd in such an environment?

We'd like to move away from sticky sessions, but need onSessionEnd for
basket abandonment type operations.

Seems we need another task to collect expired sessions (or retrieve
them just before expiry) as the web servers themselves don't know
who's responsible for clearing a session...
> https://groups.google.com/d/msgid/lucee/54E5161A.901%40lucee.org.

Michael van Leest

unread,
Feb 18, 2015, 8:41:26 PM2/18/15
to lu...@googlegroups.com
You can schedule a job to get all sessions that haven't been updated for your session timespan - x minutes/seconds (depending on the size and duration of the process). And do operations that are needed. 

Mike

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


--
Sent from Gmail Mobile

Michael Offner

unread,
Feb 19, 2015, 1:51:43 AM2/19/15
to lu...@googlegroups.com
@gert could you make a wiki entry for this ...

Micha

Dan Kraus

unread,
Feb 19, 2015, 10:42:54 AM2/19/15
to lu...@googlegroups.com
Amazon has sticky sessions with their load balancers but I think a good goal for scaling is round robin this way. This way, if any server goes down, the user's session isn't stuck in a dead server.

Using Database storage is one way to do it but depending on the traffic, I might not want it on my regular database, something that just handles sessions. It's going to be slower than accessing from memory to pull it in and out of the DB. Redis is one option. I haven't put it into production yet, only some testbeds, but I'm very likely going to be implementing it in a big way. I just wrote up a blog post about it last week.

http://www.dskraus.com/2015/02/11/railo-sessions-redis/

On Wednesday, February 18, 2015 at 10:39:30 AM UTC-6, Siegfried Wagner wrote:

Jochem van Dieten

unread,
Feb 19, 2015, 11:15:48 AM2/19/15
to lu...@googlegroups.com
On Thu, Feb 19, 2015 at 4:42 PM, Dan Kraus wrote:
Amazon has sticky sessions with their load balancers but I think a good goal for scaling is round robin this way.

Round robin is not good for scaling. With round robin every request needs to consult the common session storage. With sticky sessions the server can consult the local storage, which is typically in RAM and faster. 


This way, if any server goes down, the user's session isn't stuck in a dead server.

But that doesn't require round robin. Even if you enable sticky sessions, when a cluster member goes away the loadbalancer will stop sending it traffic and direct the user to a different server. To make sure the session is available on that server, what you need is:
- for servers to send all their session changes to the common session storage;
- for servers to read the session from the common session storage only when they receive a request which does have a session ID which is not present at the current server.

For scalability this is much better: write only changes, read once per session after a server failure, instead of read on every request. The only thing you have to make sure on your loadbalancer configuration is that it the sticky server goes away, a new sticky server is picked and the request doesn't start to round-robin.

Jochem


--

Dan Kraus

unread,
Feb 19, 2015, 12:31:24 PM2/19/15
to lu...@googlegroups.com
I understand your point. Unless I'm mistaken, I've always thought that sessions are being read on every request with CF/Railo/Lucee which would always need to read from the session store (be it local in-memory or off-server (database, redis, couchbase, whatever). 

Otherwise, how do you tell the Lucee App to read from two different session storages? Any time you write something to the session, also have it write to your off-site storage? Would something like that be best captured in OnRequestEnd() or something that would copy the session data after the request is done to your common session store?

In the case of being bounced to a new server, do you have OnSessionStart() have it read from off-site to populate the local session but if it doesn't exist create the session in both places?



--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/22_1wwR5q7c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

Brad Wood

unread,
Feb 19, 2015, 12:37:24 PM2/19/15
to lu...@googlegroups.com
I believe that is handled by the this.sessionCluster setting.  When set to true, the external storage is favored over anything that might be in memory on the server.  When set to false, the in-memory storage on the server is favored over the external storage.  I'd need to do a test, but I THINK session is always saved on request end, but ONLY read if cluster is set to true.  
My initial understanding of that setting would be for people who would like long-term session persistence across restarts, but don't have to worry about users potentially hitting a new server every request.  I'm guessing it would also do nicely for any form of load balancing with server affinity.  Basically, the user would get stuck to a single instance and use the session in memory, but in the event that server died and they get kicked over to another, it can pull their session there as well.

This is fairly easy to test with the Railo couchbase extension.  Just hit a page and see how many reads and writes happened on the session bucket.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp 

ColdBox Platform: http://www.coldbox.org 


Gert Franz

unread,
Feb 19, 2015, 12:55:56 PM2/19/15
to lu...@googlegroups.com
Brad, 

thats exactly the way the this.sessionCluster setting is supposed to be used.
I actually don't like sticky sessions, since if a server is busy it would still get requests from users that have that server stored for their sickness.
Therefore I always use round robin or any other load balancing technique.
And I set the sessionCluster to true, in order to read the sessions every time the request is initialized.

Gert

Sent from somewhere on the road
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

Charles Robertson

unread,
Jun 6, 2016, 9:51:37 AM6/6/16
to Lucee
Hi Gert

Due to money constraints, I am looking to create the most basic of set-ups:

2 X VPS with Railo/IIS7 & MySQL

I feel that it is best to use local connections to the database, for speed efficiency, so I will be using two way data synchronisation between the 2 databases.

When I create my lucee_sessions DB, can I create it locally [one for each server] and then have:

ServerA.lucee_sessions synchronised with ServerB.lucee_sessions

In this way, whenever a key is written to ServerA.lucee_sessions, it will update ServerB.lucee_sessions, accordingly.

Would I set:

this.sessionClusters = false;

Presumably:

this.sessionClusters = true;

Is only used for a lucee_sessions DB on its own dedicated DB server. Creating one single common session store, used by ServerA & ServerB

Thanks

Charlie

Charles Robertson

unread,
Jun 6, 2016, 10:04:30 AM6/6/16
to Lucee
Gert

The other part I don't understand, is that the CFID issued for the same user on ServerA & ServerB will be different. How is this resolved?

And do I need to use the same Application name [this.name] for both ServerA & ServerB, in their respective Application.cfc?

Thanks

Charlie

Reply all
Reply to author
Forward
0 new messages