Some folks, using it with CF2021 or 2023 found CF was somehow heavily impacting their Redis instance. The good news is that I've found an easy fix/workaround (until Adobe fixes it formally).

For more (including why you may or may NOT be impacted by the issue), read on.

Some background/introduction

I mentioned previously that I'll be giving a talk at CF Camp next month on why and how easily you can setup CF or Lucee to store sessions in Redis.

And for those who may start exploring this redis sessions feature (introduced in ColdFusion 2016) or who tried it and had "problems', you may find that ColdFusion 2021 or ColdFusion 2023 (not 2018 or 2016) will be sending far more requests to Redis than are to be expected. This can be observed if you use the redis CLI or gui monitoring tools to watch Redis performance, such as commands/sec.

In light testing you'd not likely even notice and issue, but it's making several requests to redis every second for every session--which in production can be killer. It's bad enough in terms of the redis instance CPU/performance, but it can hit your org's wallet if you're using a Redis service where you may pay per number of commands executed per day!

A seeming workaround: remove the CF "pmtagent" module if not using it

I'd had the problem raised to me in working with one of my consulting clients, so I dug in.

And I've found that it's caused by the "pmtagent" package/module, which can be easily removed if you are not using the CF PMT to monitor your CF instance (and to be clear, this impact happens EVEN THOUGH you are NOT using the PMT to monitor your CF instance).

For those not familiar, CF2021 changed to a new modularized approach where the underlying CF engine functionality is broken into about 50 modules or packages. And by default, a normal install of CF implements ALL of them (while a zip install or CF Docker image implements only a couple), and you can install some or "all" with the CF Admin, or the cfpm tool, or via the installModules env var used in starting a CF container, etc. (These are things I've discussed in recent past Ma href="/presentations">presentations.)

And by the same token, you can easily REMOVE any package/module using that same CF Admin UI, or cfpm tool, or the installModules container env var.

Note that if you do remove this pmtagent in the CF admin or via CFPM, while some package removals do not require a CF restart to take effect, this one does (though it does not say so in the CF Admin UI or cfpm tool).

Once you remove the module and restart CF, you should find that the traffic to redis immediately drops and is instead just the minimal amount needed to manage sessions as they are created/modified.

Tracker bug report

Of course, if you ARE using the CF PMT (introduced in CF2018) to monitor your CF instance, you can't just remove this pmtagent module. And if you do happen to have it installed but aren't using the PMT, it should have no negative impact.

As such, I have opened a ticket at tracker.adobe.com to report this problem: CF-4222211. If this issue concerns you, please add a vote to that ticket.

In the meantime, I hope this fix may help others to leverage this useful CF Redis sessions feature.

Finding out more on CF Redis sessions

While you can find the feature (its configuration) discussed some in the CF (and Lucee) docs, there's precious little. Same with discussion of it in the community. That's one of the reasons I decided to put together the talk for CFCamp next month (and I have proposed it for the CF Summit coming this fall).

I'm also considering doing a number of blog posts BEFORE the CFCamp event, both for the sake of those not attending and also to take some burden off me needing to offer as much detail in the talk. :-)

In the meantime, note a few key points:

• Perhaps the best thing about this feature is that it means you can restart CF (or lucee) and NOT lose sessions. Yay! Think of how many times you were reluctant to restart for fear of annoying users. This frees you up to more easily implement CF or Java updates, do code pushes that might require a restart, etc.
• And yes, you can have multiple CF instances share a single redis DB so as to thus share sessions with each other (same with multiple Lucee instances)
• And yes, you can use it (in both CF and Lucee) with session variables of any kind (simple or complex, including structs, arrays, queries, CFC instances, and more)
• And yes, you can use the feature with ANY redis-compatible implementations or alternatives (valkey, keydb, redict, dragonfly, memurai, and more), as CF has simply implemented a standard jedis library underlying CF. That also powers the optional use of Redis as a caching engine in CF, which is only supported by CF Enterprise, but...
• To be clear, this CF Redis sessions feature is NOT limited to CF Enterprise: it works with Standard (as well as the trial or Developer edition, of course)
• And again the CF Redis sessions feature is not new: it works with CF2016 or above (and Lucee has two Redis extensions, either of which work fine for setting Lucee to store sessions in Redis--in addition to its capability to store sessions in a DB, which CF does not currently offer.)
• And there are multiple tools (both CLI and gui--free and paid) that can make it easy to view the data within a redis DB and to observe redis performance, including this tracking of commands/second or the commands themselves
• All that said, what if the redis instance becomes unavailable, either while CF/Lucee are running or upon their startup? CF (since some recent update) will start, but any page using a session will get an error. One could argue this is just like if a primary DB used by the app went down. FWIW, Lucee just soldiers one...which is great for keeping CF up, but won't be fun if you restart it, expecting it to restore your sessions from Redis. In both cases, hopefully Redis won't be down for long--but that may be entirely out of your hands.

One last thing: using the CF Redis sessions feature DOES indeed require that you DISABLE the "j2ee sessions" feature (on the "Memory Variables" page in the CF Admin). While that will put some off (as they have been told for years that "j2ee sessions are far more secure than traditional CF sessions"), the fact is that CF sessions can be configured to be just as secure, whether at the CF Admin level or per application. But that's a topic for another blog post...probably my next one in this series.

For now, this has gone way beyond the focus of this post (and in fact I may well split this last section into its own post, as it may be better as a part 2. But I didn't want to withhold it as some might have wanted to ask in comments if I didn't address them). And these are indeed all topics I will cover briefly in the talk, but as much as this is on the surface a "simple" topic, I do think a series of posts on it would be helpful.

I'd appreciate hearing from anyone who does apply the workaround, whether it helps or not.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed