Right, I get that it’s never going to be as fast as if it was in the same memory space. That’s just a trade-off with clustering.
But I guess my assumption was that redis will be faster than a database that’s reading/writing to disk. And that should be fast enough, as you were sort of implying?
Yeah, I think you’re on the right page. I don’t think Redis would be any faster than Couchbase or memcached FWIW. SQL server yes because its ACID requirements have to write to disk as part of the transaction. But the rest of the lot can store in memory right away and then have “eventual consistency” on disk asynchronously.
Ortus has done a lot of externeral session clustering for our clients using Redis and Couchbase (using our extensions we wrote) and the only time session storage has been a drag was when the Redis or Couchbase server went down, lol. So overall, it’s very performant in my experience. And we always use sessionCluster=true for pure round robin load balancing.
I have looked at Ortus Redis Cache but you have to buy a production licence and we have many, many, many lucee apps we want to containerise and autoscale. It may be the best workable solution but, for POC, performance questions aside, as far as I can tell the configs I put above should result in this being true:
data written to a session on node1 should then be readable from node2 on a subsequent request without any further config or DBs.
Is that correct?
If so, I must have done something else wrong somewhere or it is a bug of this built-in feature. I am writing a struct to session in my test but only once. I cant event read the struct from session on another node let alone change it. I am using the lucee:5.3-nginx container but I have seen the same on a VM install of 5.3.8.206.
Thanks again 
We have a “Large” container license which covers up to 20 Lucee instances. You can also reach out to negotiate a custom pricing arrangement.
We have a trial license you can use to test. I understand, of course, if you decide to use the free one. I’ll just say, we created our version due to lack of functionality and lack of support in the free one. We needed to give our customers something we could support. And it seems like that’s what you need 
I have no idea what this part of the docs is referring to. I’ve never heard of issues with CFML sessions in docker containers and I’d question who wrote this and ask them to explain it. I certainly wouldn’t take it as gospel truth, even though I realize it does appear in the official docs.
No, not at all. I mean, you can try to use Tomcat’s session clustering, but I’ve never used it and I’ve never heard of anyone else using it, and I’m not even sure how it works. Everyone else in this thread is talking about using “cfml” sessions and using Lucee’s session storage in a cache.
I would also point out there that Lucee’s container isn’t the only game in town. There is also the Ortus Solutions CommandBox-powered docker containers which are far more flexible and far more configurable than the core Lucee ones. Full disclosure, I work for Ortus. 
https://hub.docker.com/r/ortussolutions/commandbox/
I can’t verify that, in fact I’ve never heard of it. if it’s in the docker readme, it was probably typed by @modius or @justincarter so perhaps they can chime in on it.
If you remove the logic manually fiddling with cookies, does it change the behavior your see?
In theory, yes. Debugging session clustering can be a bit of a pain. I would start by confirming your browser does NOT get a new CFID or CFToken cookie when you switch containers. That means the domain name must be the same and the CF code must not be change it. If your CFID is changing, then figure out why.
It’s also possible there is an error in the underlying cache/datasource that is handling the sessions. Lucee used to blow up the whole request when the cache couldn’t be reached, but at some point I’m fairly certain it started just swallowing errors and perhaps maybe logging them somewhere. If you have the ability to monitor your cache/DB reads/writes, that can be helpful to see what interactions Lucee is making to them.
Thanks for all the info
Yeah adding/removing the manual cookie manipulation was just experimental. It made no difference.
I can confirm the cookies were the same, when I switched clients I sometimes used the cookie from the original client, sometimes it was just the same client connecting to different nodes. Result was always the same 
the session stayed on the node, despite appearing in the DB as well
From what I can tell from everyone’s feedback though the code fragments I have given above should do the trick and it is either an environmental problem, which I will investigate further, or a lucee bug (which I will raise, if so).
I am on other projects at the moment. When I am back on this I will update this thread with more investigationalised outpourings.
Thanks again, all!
So sorry for missing this, even though I was tagged in the convo at one point 
I think I can clear up one bit of confusion. The advice about the “cfml” vs “j2ee” sessions is from the legacy Docker Hub repo readme. That page is ~5 years old and the advice wasn’t quite right (perhaps I’ll manually edit that page to remove any future confusion);
https://hub.docker.com/r/lucee/lucee5
Using “j2ee” sessions did work around a clash with the application sessions vs Lucee Admin sessions – sometimes two different cookies were set, and one of the cookie’s domains had a leading “.” whereas the other one didn’t, so logging in to the Lucee Admin could break an application that used “domain cookies”, I think… It was not related to Lucee’s Session Clustering feature as such, and the recommended setting for that is “cfml” sessions not “j2ee” sessions.
That old advice had been removed from the current readme in around 2018, and ever since the latest Lucee 5.2.x releases all the newest Docker images are published to a single unified repo at:
Just an update for everyone. I have returned to this today and clustered CFML sessions in 2 Lucee + NGINX pods seems to be working. Last time I made so many config changes to try and get it working I need to play with them to work out which are actually required and which are not. I will then dump the deets in here FFR.
OK this is definitely working. I have tested it on multiple websites load-balanced by haproxy across
The configs that worked were all in Application.cfc
// Application.cfc
// Tested configs working, these were just for POC
this.name = left(cgi.server_name,20) // scope sessions in DB to this app
this.sessionType = "cfml"; // dont use JSESSIONID
this.sessionStorage = "luceesessions"; // datasource name
this.sessionCluster = true; // for sessions DB = source, memory = sink
this.setClientCookies = true; // send CFID -> browser
this.setDomainCookies = true; // scope to domain name
this.sessionCookie = {
httpOnly = true,
secure = true,
domain = cgi.server_name, // lucee prefixes with "." but works ok
timeout = "-1",
sameSite = "lax" // will also be trying Strict soon
};
And that is it. No cookie manipulation. Works a dream in our standard AJAX multi-site apps, with manual login and with OIDC.
We are about to start trialing with targeted staging installations