0

I have two multihomed, web-balanced webservers running Lucee and I'm having issues getting the session to replicate across EHCache instances. I'm not even sure if auto discovery works

Here is my setup and config:

OS setup

  1. Multicast setup for both servers on eth0 with address 224.0.0.0 (I know this works because when I ping 224.0.0.1 I get responses from both webserver IPs)
  2. /etc/sysctl.conf: net.ipv4.icmp_echo_ignore_broadcasts = 0 and net.ipv4.ip_forward =1

Lucee SessionCache object setup for each instance

  1. Auto Peer Discover
  2. Multicast User Group Address: 224.0.0.1
  3. Multicast User Group Port: 4446

  4. Host: xx.xx.xx.xx (this is the IP address of each of the server's eth0 interface that I'm using and I did confirm that they respond when pinging the multicast user group)

  5. Synchronization has everything checked

All other settings (RMI, Listener) are left as default (blank in some cases)

When I run my application which uses this sessionCache object as sessionstorage and attempt to login, I only login on one instance then get redirected(load balancer) to the next instance where I have to login again because the session does not get replicated.

Update #1

In order to enable the session replication in a distributed cluster, you need this.sessionCluster = true and J2EE session types (this.sessionType = "j2ee") in the Application.cfc pseudo-constructor

Update #2

Distributed cache for session storage seems to be very prone to race conditions even with synchronous replication. Asynchronous replication is definitely not recommended, especially when your load balancer does Round Robin.

Which brings me to load balancer Round Robin. Lucee creates a brand new session every time you jump an instance, so my replication is useless because I'm not hitting the same sessionid

Update #3

Storing the sessions in a database through the sessionStorage property seems to mitigate all my issues. I can even do Round Robin in the load balancer. Instructions on setting that up can be found here. CFML sessions are recommended instead of J2EE

dwkd
  • 2,716
  • 1
  • 17
  • 17
  • 15 years of working with CFML in clustered environments my experience has been avoid anything session scope related it just does not work properly without jumping through hoops. We set our our own session cookie with homegrown session management code that a database as a backing store. We know how it works and we don't need any fancy setup, works without sticky load balancer settings in all LB schemes we have needed. using the built in railo backing store is ok, but even with that there are issues. – M.Scherzer Jun 30 '15 at 01:29
  • can you provide some examples please of issues with the Railo db session storage? it seems to be holding up great in a Round Robin LB scheme – dwkd Jun 30 '15 at 13:53
  • Admittedly it is an edge case but we needed changes to session scope to be as close to instantly visible across the cluster as possible. At least at that time railo did not flush the session data to the database until after completion of the request (which makes sense to keep load down). However we had code that we could not optimize further that ran for at least 2-3 seconds meaning any request that come in on other servers were seeing old data. Being an AJAX heavy app we always had multiple request firing. when we displayed data from the ajax request mixes results would be displayed. – M.Scherzer Jun 30 '15 at 14:18
  • I was reluctant to trying this the first time around because of that exact comment in a Railo wiki. They do say that Railo does session management in memory and it dumps to db after 10s or so. Obviously that would not work in a cluster where you bounce around every request. However that is no longer true. The session seems to be in sync with the database [at least] at the end of each request and is triggered with redirects from any point within the application (reqstart, req, reqend, etc) – dwkd Jun 30 '15 at 19:37
  • I can see the increased potential for race conditions with ajax heavy apps but that could be mitigated with how you implement the crud functionality and the checks performed before each crud operation to check for stale or out of date data – dwkd Jun 30 '15 at 19:41
  • yeah we mitigate it by not using session scope. as i said we are edge case and session scope is great for certain projects. good to know they fixed the 10 second thing. – M.Scherzer Jun 30 '15 at 23:29
  • yeah, an alternative is the request scope, which is probably what you're using. Thanks for chiming in – dwkd Jul 01 '15 at 02:40
  • 1
    @dwkd Here is another excellent link on your Update 3: https://rorylaitila.gitbooks.io/lucee/content/clustering.html – Charles Robertson Jun 06 '16 at 16:48
  • @dwkd Update 3 is definitely the way to go. Can I ask whether you are using a dedicated DB server with lucee_sessions DB. So, this DB is being accessed by both your Railo Servers? – Charles Robertson Jun 06 '16 at 16:51
  • @dwkd Is it possible to have lucee_sessions DB on both Railo Servers, so that DB requests from the application are local & fast? Then you use MySQL synchronisation to keep both DB identical? – Charles Robertson Jun 06 '16 at 16:54
  • 1
    @CharlesRobertson I am using a dedicated DB server with the sessions table on it. You can have lucee_sessions on both web servers, kept in sync but I'm not sure MySQL sync won't cause race conditions and it's definitely not scalable; i.e. adding a 3rd web server, and a 4th.. All in all I feel like whatever cost you gain from local dbs you lose in the mysql sync operation. A dedicated DB server in the same datacenter/rack should be the way to go IMHO – dwkd Jun 06 '16 at 17:46
  • @dwkd Yes. I agree with your race condition theory. I am going to opt for a dedicated DB server, when I set up my cluster. – Charles Robertson Jun 06 '16 at 21:09

0 Answers0