Using Redis as a cache for Lucee

dev support
1

Redis is used a lot, especially by @micstriit so the Lucee support is actively maintained, the Lucee extension uses BSON for efficient storage

but they did one of those licensing shifts, but there’s a fork

https://valkey.io/

Lucee has some additional commands for Redis as well

1 Like
2

To add to Zac’s helpful reply, redis replication is indeed easy, as shown in their docs on it or as other resources online (found easily via web searching/ai) will show.

As for that redis licensing change, I’ll add that it was not a change that directly affected those USING redis, including the open source community edition. Still, there’s no doubt it caused widespread consternation as well as acceleration of interest in and evolution of alternatives like Valkey.

But it was mainly aimed at protecting them against providers selling redis as a service (but not paying anything to redis) or creating competing redis engines or services. For more details, including frequent q & a’s, see Redis Adopts Dual Source-Available Licensing - Redis

FWIW, I discussed this and listed still more redis alternatives in my talk at cfcamp last year, which was on using it/them for cf or Lucee sessions specifically. That talk (pdf and youtube video) are available here.

Looking forward to seeing folks again in Munich next month! :slight_smile:

1 Like
3

That’s great, thank you guys. I’ve got two servers talking to the same Redis (Valkey on ElastiCache), which is awesome. I just need to implement an alternative to the KEYS command (i.e. SCAN) as this isn’t supposedly supported with AWS for performance reasons. This errors when it tries to validate the cache connection in the Lucee admin, and also within our implementation when trying to clear a bunch of related entries.

I’ll work that out later, but back to the day job for now :slight_smile: Thanks again!

4

ah interesting, I filed a ticket

https://luceeserver.atlassian.net/browse/LDEV-5502

btw, I have split this out in a new thread

5

Thanks for splitting the ticket Zackster. Unfortunately I just got around to trying out the Ortus Redis extension and it seems to have the same issue/incompatibility with AWS.

ERR unknown command ‘keys’, with args beginning with: lucee-cache*

lucee.runtime.exp.NativeException: ERR unknown command ‘keys’, with args beginning with: lucee-cache* at redis.clients.jedis.Protocol.processError(Protocol.java:96) at redis.clients.jedis.Protocol.process(Protocol.java:137) at redis.clients.jedis.Protocol.read(Protocol.java:192) at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:335) at redis.clients.jedis.Connection.getOne(Connection.java:317) at redis.clients.jedis.Connection.executeCommand(Connection.java:131) at redis.clients.jedis.Jedis.keys(Jedis.java:5083) at ortus.extension.cache.redis.RedisCache.keys(RedisCache.java:320) at ortus.extension.cache.redis.AbstractRedisCache.keys(AbstractRedisCache.java:328)

As an example, we might cache all the data for a given student with an object name/path starting with the record UUID, so to clear all cached data for the student we need to get all keys starting with the UUID and clear them. So having cacheGetAllIds() working is critical.

P.S. This issue was coming up with using Valkey on ElastiCache, but I thought I’d try Redis OSS on ElastiCache instead and that works. So it doesn’t look like the KEYS command is restricted on that instance type… for now :slight_smile:

6

Sorry for this saga continuing and apologies if this should be posted elsewhere but…

  • I had two caches defined on the server, one pointing to the Valkey instance and one pointing to the Rediss OSS instance. For the OSS one CacheGetAllIds() worked - awesome! As per my previous comment. However, I deleted the first cache and renamed the second - and it started throwing the error. Configuration was exactly the same! Wondering under the hood somewhere the connection details are cached or something - I’ve restarted each time changing the configuration. So it still works using the second cache name, but not the first.
  • I set up the Ortus extension on the other server we want talking to each other, using the working configuration from the other server, and it is throwing the error (with any cache name). They are on the same version of Lucee, I’ve diffed CFConfig.json and I can’t see any difference that would account for it working one place and not the other.

I guess at this point I need someone at Ortus to confirm how the implementation of cacheGetAllIds() works - does it use SCAN - is it conditional? Any reason it might work in some situations and not others? Are the connection details cached anywhere else than CFConfig?