http://coldfusion.com logo
Join Slack
Powered by
is there any documentation at all on how to use th...
# lucee
j
is there any documentation at all on how to use the lucee redis extension (recently rebranded as 
Redis Sentinel driver (BETA)
) for sessions? i had been using it a while back until it started failing, at which point we started using the commercial ortus extension. we're trying the native extension again and it's logging out sessions after 10 minutes (instead of the Application.cfc's 120m timeout).
but i'm not seeing any documentation for how to implement session storage with the native extension so i don't know if there's some, say, timeout/ttl that i'm supposed to be setting.
e
timely post... wish i had an answer, but i was just about to revisit this after my own failed redis experience a couple years ago.
s
We use the regular (not sentinel) extension and it works pretty well, although we've had a PR or two in on that project for > 1 year and can't get anybody to look at it. The paid Ortus extension is gonna be a much better bet unless the Lucee one 'just works' ... I think Lucee devs only really pay attention to it when they need it for clients
e
Are you using Redis or Elasticache?
j
@sknowlton, is there even any difference between the sentinel and non-sentinel version? it's got the same extension id, i think it just had a superficial rename.
@emmet, redis
s
You might be right. I've never used the Sentinel version as we don't cluster redis, so I couldn't say with any certainty
j
i'm curious as to which version of the extension you're on @sknowlton
s
3.0.0.56-SNAPSHOT
we just updated from .54 last week I think
in Application.cfc we have:
Copy code
this.cache.connections[ "sessionStorage" ] = {
				class : 'lucee.extension.io.cache.redis.simple.RedisCache',
				bundleName : 'redis.extension',
				bundleVersion : '3.0.0.56-SNAPSHOT',
				storage : true,
				custom : {
					"minIdle" : "0",
					"maxTotal" : "1000",
					"maxIdle" : "200",
					"host" : clientProfile.redisHost,
					"password" : "",
					"port" : "6379",
					"timeout" : "2000",
					"timeToLiveSeconds" : "7200",
					"databaseIndex" : "-1",
					"namespace" : clientProfile.appName
				}
			};
Not sure if 
namespace
does anything or not, I know Ortus' extension used it and I can't recall if Lucee added it to theirs yet
j
i don't remember how i ever knew how to configure the extension to begin with because i don't see documentation now. mine looks like this: https://gist.github.com/jamiejackson/35969572434b35622e1551aa905d63a3
s
I believe the cache config in Lucee admin shows you a snippet you can paste into Application.cfc
🙏 1
e
Are sessions extending on session activity now? thats where i gave up the last time i tried this.
j
note that i don't have the ttl or timeout that you do, @sknowlton
attn: @ajay
s
I believe they are but assign a low reliability rating to that statement 😅
Our app doesn't see a ton of long sessions such that many people would complain, but a couple people would, and nobody has. So obviously it's working perfectly
goes on vacation
fingers crossed 1
j
is that what you found, @emmet, that sessions weren't being "freshened up" after the intitial expiration wa set?
e
Yep. The seemed to cutoff at the ttl.
j
okay, that's something for us to look out for, then, thanks.
Not sure if 
namespace
does anything or not, I know Ortus' extension used it and I can't recall if Lucee added it to theirs yet
I requested it from Ortus a while back but it hasn't happened yet: https://ortussolutions.atlassian.net/jira/software/c/projects/LRE/issues/LRE-46
or it doesn't work as expected.... or something like that
a
@jamiejackson we are on 
3.0.0.51
t
@jamiejackson we are in the process to moving to 3.0.0.51 and we do use sentinels in our environments. The namespace was dropped in the new version of the Lucee Redis driver. We have a wrapper to manage our namespace and had to work around the lack of sentinel support in the lastest versions of redis extensions. We wanted to keep our HA Redis Sentinel clusters have worked around that issue now.
j
@ajay (who's on my team): it seems like @sknowlton is doing tentatively okay on 3.0.0.56 and @tony seems to be doing alright (with presumably a somewhat modern version of the driver, though not as new as our 3.0.0.51). so maybe it's just a timeout/ttl config thing in our config.
l
@jclausen
j
tldr for ortus folks: ortus redis extension works fine (though we still are missing the namespacing stuff).
i'm just trying out the lucee "native" version since it's gotten some commits since i last tried it.
s
the ortus one is superior across the board, it's not even close
in basic 'cache a thing and get a thing' they're both great, but when something (inevitably) comes up ... you aren't waiting a year for attention to an ortus pull request
👍 1
l
@jclausen just added distributed locks and more high performance tuning settings
If you need anything we will build it
👍🏼 1
j
if i'm reading that ticket correctly, that ticket is still open
s
the ortus connector supports namespacing but idk about the 
:
format for them
l
I actually think this is possible now. Wr always prefix a cache entry according to the cache you configure. But the name of the entry is wide open.
You can use that convention now
👍 1
e
@lmajano is distributed locks in the current release or your next release?
nvm... i see its in 3.3.0
☝️ 1
j
3.3.0 is published, so it’s ready for use.
e
@jclausen have you tested with AWS Elasticache? I'm assuming it still works.
j
@jamiejackson: let me know if LRE-46 is resolved. If it’s not behaving the way you expect it to, please let me know and give me a code sample use case so I can figure out what needs to happen. @emmet Yes. Both in cluster and single node mode, Elasticache is good to go.
👍 1
e
Great, thanks.
j
TL;DR: I think LRE-46 is fixed. @jclausen, i've lost the original email thread between luis and me about adding the namespace capability and the details didn't make it into the resulting ticket (LRE-46). however, i have some some vague information in one of my own project tickets. a side effect of using, say 
foo:bar:baz:
as a key prefix seemed to have been that leaf keys would end up having a hyphen before the name. i no longer see that prefixing issue happening, so i think as we've upgraded the redis extension on my project, the ortus enhancement kicked in at some point.
I'll mention it's fixed in the ticket.
and by the way, i give up on the native lucee redis extension. i don't think i'm going to (ever) revisit again. "twice bitten" and all that. it fails fairly reliably on production (sessions die after 10 minutes), it fails ~50% of the time on stage, and we can't get it to fail on local development. i'm not too interested in troubleshooting it further (apologies, lucee redis community). maybe it has to do with load or number of sessions but we've got bigger fish to fry on my project. back to the ortus version, for good.
@jclausen, i see that there are is a (paraphrasing) single instance option and a cluster option in the license page. what's the difference? (we're on single-node redis now but we'll eventually go to managed elasticache)
j
> i see that there are is a (paraphrasing) single instance option and a cluster option in the license page. what’s the difference? That’s not for usage of the extension against Redis, but just for the number of production instances you intend to deploy Lucee with the extension on. With any license, you can connect up to single, or cluster instances ( as many and as big as you like )
j
Oh, right, of course. Makes sense.
5 Views
Open in Slack
PreviousNext
Powered by