Coldfusion not expiring session with Redis

[CurtangWarrior]

Hello,

I am running CF2018 update 9 with Redis session storage enabled and I am finding that sessions are not consistently expiring on their configured expiration durations.

Currently in CFAdministration I have the maximum session timeout set to 30 minutes, the default to 30 minutes, and in Application.cfc the timeout configured for 30 minutes.

We are finding that often our session will not expire even after several hours of inactivity.  Has anyone else seen this?  Perhaps knows what could be going on?

Thanks,

-Curtis

[Charlie Arehart]

Curtis, I know you first chimed in today on the other long thread on Redis sessions that seemed not to be expiring (https://community.adobe.com/t5/coldfusion/redis-session-keys-not-expiring/m-p/11180920?page=1), and you opted to instead create this new post, in case this may be a "different" issue. I guess we'll see. 🙂

So first, did you at least catch and consider the extended reply I'd offered there, where I elaborated how one could watch things going on in Redis? That may help with your investigation of things. I do appreciate that mine and the comments from others did make for a lot of reading. I'm just wondering first if you're saying you did consider it all. If you did not, I'll come back to it in a moment.

But let's turn to your situation, that the sessions never seem to expire.

First, how are you tracking that? You may well just be simply testing pages. Hopefully you are waiting at least 30 mins between checks, as each call to such a page will restart the timeout clock to a new 30 mins. I know you say you find the sessions are there "after several hours of inactivity", so again just checking.

Perhaps you are watching with a tool like FusionReactor or the CF 2018 PMT?  If you are, that may be actually CAUSING the issue.

The mere act of having the PMT enabled and monitoring a CF instance has been known (and reported) to cause problems with CF sessions. It was reported first as a bug report and then as a blog post by the FusionReactor folks. They found it, and they stopped FR from tracking details of Redis sessions (though they still show the count).  Adobe has said as recently as last month that they have not yet resolved the issue yet.

Now, both those talk about the PERFORMANCE impact (high CPU) of some unexpected and excessive ACCESS by the monitoring tools to the Redis store, to track the sessions. Neither the tracker report nor the FR blog post speak of any impact on session timeouts (or unexpectedly keeping the session from timing out).

But that certainly COULD be happening. And that's why I asked if you are using either tool to monitor your CF instance, and if that's how you knew that sessions were "not timing out". If you ARE using either, what if you stopped?

As for FR, you don't really need to stop using FR, at least if using version 8.2.3 or above, as they stopped their impact. If you don't know if FR IS monitoring your CF instance, you can look in the CF Admin "java and jvm" page, and the java args field, to see if it refers at all to fusionreactor (you can also open the CF jvm.config file and look for it in there).

As for the PMT, you can't stop it being monitored from inside the CF Admin. Instead, you need to go to the PMT (wherever it's installed, which could be another machine) and tell it to STOP monitoring the CF instance in question. And if you may saw you don't know if the CF instance in quesiton is being monitored by the PMT, you CAN find that by going to the PMT page in the CF Admin (use the new CF Admin search feature in CF2018 to find it). That PMT page has an indicator of whether the instance is being monitored by the PMT.

I do understand that "stopping the monitoring" may be a solution some will balk at. I'm simply proposing you do it for investigation sake, even if only for the hour needed to confirm if sessions do again start timing out.  (Just remember that they do only timeout after inactivity, not 30 mins after creation. So it's not unsual to have sessions last "longer than the timeout".)

If you might confirm that you don't have EITHER FR (older than 8.2.3) or the CF PMT monitoring this instance, I realize you may feel you are stuck. And perhaps others may have new information (none was offered in the other thread). But until then, I will again encourage you to use the Redis diagnostic tools that I referred to in my comment in the other thread.

Do let us know how things go.

[CurtangWarrior]

Hi Charlie,

Thanks so much for replying.  I did read through the entire other post and many others here and on other professional sites that I thought might be related.  The reason I believed it was different was the original poster found that it was in fact scheduled tasks that were leading to the session keys remaining.  In our case we do not have any scheduled tasks (other than the typically CF update check) running on this server.  Even if we did have scheduled tasks running on this server, that would be a serious issue as a scheduled task executing should not lead to a user session remaining active.  They should be in seperate sessions.  We also do not have PMT or FR running this is a simple dev environment with little going on.

Our method of checking is as you stated simply checking pages.  In our case right at the beginning of OnRequestStart we perform a structKeyExists(session, 'site_set').  If this is false we redirect to login.  However on several occasions now, I personally have left for 2+ hours and come back only to find my session still valid.  We have a test page that dumps out what is in session so I checked it in case somehow it had reset with just the base login session values, but it still had all session values from my earlier session.  I have also had several colleagues tell me that they have been able to come back the next day and just continue w/o logging in.  One of them claiming he had even closed his browser which I think would eliminate any possibily of some JS/AJAX script executing and keeping the session alive.  And as a note we do not have any heartbeat js scripts in our application that would lead to session remaining alive in any case.

Now this issue appears to be inconsistent.  As I did modify the timeout to 2mins yesterday and as expected I tested after 3 minutes and was returned to login.  However, set it back to 30 minutes thinking I was maybe just losing my mind. Then left for almost 2 hours for meetings came back and the session was still valid.  Hence why I am having trouble determining what is going on.

On a possibly related note, I was able to find a bug with Redis session on the current CF2018 release that Adobe was able to replicate.  In this issue, setting any value to session scope in the OnError function was not working.  It wouldnt error, the value just would not set so when we went to view it after recieving the error, the value would be empty or non-existent.  This also appears to be somewhat inconsistent but this combined with the session timeout issues is certainly concerning.

I have logged in with RedisCLI but have not yet caught/identified a key set remaining past its expectancy.  I will see if I can set up redisinsight and capture something as you have suggested, but again the inconsistent nature does make it somewhat difficult to observe.

Thanks again for your follow up.

[Charlie Arehart]

Hey curtangwarrior, I realize this thread is more than 3 years old, but did you ever get to the bottom of the issue you'd faced? 

[BKBK]

  Even if we did have scheduled tasks running on this server, that would be a serious issue as a scheduled task executing should not lead to a user session remaining active. 

By @CurtangWarrior

Just a remark to address that point. If a scheduled task runs as a user, and it reruns at intervals shorter than the session-timeout, then the session will remain active.

Having said that, I must admit that Redis sessions not timing out seems to be a recurring issue. You and Charlie have already mentioned some related discussions in this forum. In addition, a quick search of the ColdFusion-bug-database reveals the following bugs were reported - and fixed - within the past 4 years:

https://tracker.adobe.com/#/view/CF-4211186 
https://tracker.adobe.com/#/view/CF-4211569 
https://tracker.adobe.com/#/view/CF-4215586 
https://tracker.adobe.com/#/view/CF-4219172 

So you might be on to something. But, before we think this is a bug, there are situations to rule out. You would have come across some of them in your research:

1.  De-select "Use J2EE Session Variables" in the Administrator, if you had selected it. You cannot store J2EE sessions in Redis.
2.  If you use a load balancer, then disable sticky sessions for the nodes in a cluster.
3.  If using a cluster manager, deactivate Sticky Sessions and Session Replication.
4.  Add a call to sessionInvalidate() in the onSessionEnd event-handler. Something like 

	<cffunction name="onSessionEnd" returntype="void">
	   <cfargument name = "SessionScope" required="yes"/>
	   <cfargument name = "AppScope" required="yes">
	   
	  	<cfset sessionInvalidate()>

	</cffunction>