Redis Session Keys not Expiring

Jojo, I have done some more investigating, and I think I have what should be seen as good news. The bad news is that I'm not sure things are quite how you have described them to be.

Let me be clear: I'm not denying there's no TTL on the keys. But I am saying that I've found that the sessions do not pile up in redis, unchecked. CF is itself managing the deletion of the keys, when IT detects that the session times out (per the timeout set for the session, in CFML). I have confirmed this with both CF2018 and 2016, with both their latest updates and earlier ones.

Let me be more specific: you opened the thread here saying that redis session keys created by CF's redis storage feature (new in CF2016) are "not expiring", and that "they basically just fill up the store", which you affirm because the redis CLI's TTL command shows that "the key exists but has no associated expire".

While it is true that the keys CF creates have no ttl, it is NOT true that the keys "never expire" and therefore "fill up the store".  First, I could see in Redis (via its cli, or other tools) that a session I created to last for, say, a minute did in fact disappear from both CF and redis after a minute (assuming there was no interaction with CF for that session id, for that minute). I could even see it in as short as a 10-second cf session timeout (I did not test still shorter timeouts).

Second, besides using the CLI or other tools (such as redisinsight or redis commander) to show whether the keys existed in redis or not, I also ran a profiler against redis (the one included with the free redisinsight tool), and I watched as the timeout passed, and I did see CF issue to redis the hdel and srem commands to remove the keys (and sets and hashes) associated with a given CF session.

So I will ask you: are you saying that you did NOT see such deletion of the keys/sets that CF is creating for a given session? (For those not familiar with redis, a set is a group of related keys, and the session var names and values for a given session are stored within such a "set" in redis.) Each session also has some related "timeout" and "metadata" information.

Perhaps you ARE finding some session data remains inside redis, but an interesting question is whether a) perhaps a problem can happen where CF doesn't delete sessions if CF crashes during the timeout, or b) perhaps CF uses that timeout or other data tracked (one of which is a "max inactive interval", which reflects the internal CF session timeout interval) to run clean up tasks even after such a crash. I don't know, and some of the keys and their values are encoded and hard to parse, but maybe with this additional info and encouragement you or someone else may want to dig in further to see what's going on in that respect.

But I can say with 100% confidence that CF IS indeed deleting sessions from redis when they timeout within CF. I'd be curious to hear more about what you are seeing that seems to be "sticking around longer". Maybe if you or someone else figures out the encoding of the data within the keys and related metadata/timeout info, you might find that what you have are sessions with just really long session timeouts.  (The default setting in the CF Admin is that the max session timeout is 2 days, while the default session timeout is 20 mins. Those could be changed in the CF Admin, or the timeout can be set in your app, of course.)

And of course, as long as a request is made on behalf of a session, that session will not timeout--so sessions can indeed last much longer than "the session timeout". (I added this sentence after my initial posting of this reply.)

Maybe someone from Adobe will chime in with still more details to help about the above. But I would love to hear what you think of what I've shared, and maybe you might share if you are using anything other than the CLI  to see what's in there.

One last thing: it can of course be challenging trying to watch what's going on against a redis that's being used with CF sessions in production, in that there will be so much data there. If you could setup a simple independent redis instance (like I did), you may see things more readily like I did. One can do that using any of many means, from available installers (that could be implemented locally for free, along with a free CF dev edition), or using Docker (for CF or Redis or both), or using available redis services (including redis labs, which offers free and commercial cloud deployments, so you need install nothing).

Hope that's helpful.

What is the value of the sessionTimeout setting in your Application.cfc/Apllication.cfm file? If it is a large number, then ColdFusion might not expire sessions.

Additional info - example: 

127.0.0.1:6379> TTL cf:sessions:metadata:5809_4ca8573ff508a83d-7F867DF7-076A-99F3-A7C10E2598299662
(integer) -1

According to Redis docs:

The command returns -1 if the key exists but has no associated expire.

I am not aware of there being a generic problem of that sort, but you say you are on CF2016 "sp7". By that I assume you mean "update 7", and to be clear there are 6 more updates you have not applied. Maybe if you do those updates, something among their hundreds of bug fixes may well address this issue. You could dig through the technotes for each update, and their link to the page for "bugs fixed" in each update. Or just do the latest update, and try again.

I will note that even if things were "fixed", then by an update, I would NOT expect it to affect the EXISTING sessions in redis. But it should (if there was a fix) affect sessions created from that point forward.

Let us know if you give that a try. Otherwise, you would want to look into redis to see what info it has for the expiration of the keys that CF is creating. There are free tools like redisinsight that can help with that.