Intermittent Logout Issue - Session Expiry without Clear Cause

We are encountering an issue where users are being unexpectedly logged out of the system after random intervals, ranging from 5 minutes to 20 minutes or even longer. Despite thorough checks on the application configuration, session locking, and implementing additional logging to track requests, we have not been able to identify any specific patterns or requests that could be causing the session interruptions.

We have tested the system with multiple users, but the issue persists without a clear cause. We would appreciate guidance on further diagnostic steps or recommendations to help identify and resolve this issue.

Thank you for your assistance.

Don’t forget to tell us about your stack!

OS: Windows
Java Version:
Tomcat Version:
Lucee Version: 6.2.2.91

There’s been a lot of work on session management since 6.2.2.91, could be you’re just battling tech debt?

https://luceeserver.atlassian.net/issues?jql=labels%20%3D%20"sessionmanagement"%20ORDER%20BY%20updated%20DESC%2C%20fixVersion%20DESC

Did you try the latest 6.2 release?

i have tried 6.2.5.48 and then 6.2.6.19, the problem stays the same.

You can enable detailed logging, i.e. trace for the scope log which explains what Lucee is doing in the background

Better in dev than in prod if possible, it’s rather verbose

Otherwise, code speaks louder than words, perhaps you can create a little github repo with an example with demonstrates the problem / setup?

First, are you sure it’s not that Lucee is unexpectedly restarting on you? Don’t presume that “can’t be happening so frequently” or that “it would be down long enough we’d expects to have seen outage messages”. It can restart fast (shut down and start) in many situations. And there are scenaries that can cause any app server to go down frequently–until the problem is resolved.

Zac offered some suggested diagnosis. For my first point here, simply check the logs (again, don’t presume “it can’t be that”).

Second, you indicate doing logging of requests. For this specific problem, log especially the incoming cookies for each request…or at least when a new session starts.

BTW, don’t look to the cookie scope for this: that can reflect a cookie set at the start of request processing such as one just created for a new session. Instead, look at the cgi.htrp_cookie variable. Often this proves VERY eye-opening in cases like yours.

(And for now I suspect you’re presuming the problem is “with Lucee”, but prove first exactly what’s happening, then figure out why.)

You may find there are NO cookies coming in, for these users “losing sessions”. That would cause creation of an. ew session. And of course it’s natural for a first-time visitor, or an agent that never sends back cookies, even on repeated requests where Lucee sets them. Focus on these users of concern. Then you’d explore how that could be happening.

Or perhaps the cookies (or some aspect) changes from one request to the next (for a given user), making Lucee think it needs to start a new session.

I know this may seem like hard work, but it’s really not. Since you asked for “guidance on further diagnostic steps or recommendations to help identify and resolve this issue”, these steps have helped spot the cause of problems like yours.

If nothing else, you’d have better evidence to present to explain the scenario.

I’ll note also that if you had FR, that can help also. With it you can easily see restarts, incoming cookies, counts of sessions, and more. And these things are logged, not just visible in the ui.

Finally, if indeed the loss of sessions is due to unexpected Lucee restarts, note that beyond preventing those another option to consider is storing sessions persistently, whether to a database or to a cache like redis. Both are options configurable in Lucee. And I did a talk at a recent cfcamp on using redis sessions (in Lucee or ACF), which is available on my site, Presentations by Charlie Arehart, including the pdf and YT recording.

And if you don’t succeed on your own or with guidance here over time, note that I’m available to offer remote screenshare consulting, in as little as 15 minute increments. For more on my rates, approach, satisfaction guarantee, online calendar, email, phone, and more, see Charlie Arehart's Server Troubleshooting Consulting Services.

But I’m sure there will be more offered here for you to consider. Hope you get to resolution soon and easily.

  • what session type / config / storage are you using
  • are the users losing their session, or just their login session properties
  • does onSessionEnd fire for the lost sessions?

We started noticing this when doing a clean upgrade to lucee 7.0 and J2E sessions. I suspect a tomcat upgrade/java was the culprit, but switching to application sessions using a database for storage resolved the issue.

Interestingly it seemed as though (irrespective of session timeout settings in lucee) the sessions were timing out 1 hour after they were first created. Made it hard to debug as most reports would note when they logged in bit necessarily when they first accessed the application.

ahh useful data points

few questions, been deep diving into the code

  • has this regressed from a previous Lucee version or from ACF, if so which versions
  • how do you deploy lucee, docker, installer, command box?
  • this happens with a plain old lucee instance in dev?
  • just lucee in the mix, no other apps using the jsessionid?
  • is sessionCluster enabled?

We noticed the change after upgrading from 6.2 to 7.0 a month or two ago.
This was done as a clean install.
Our setup is Lucee (direct install) on a Ubuntu VM behind Apache.
Nothing else interesting going on, and certainly nothing else using jsessionid (we have very few config changes from default outside of .cfconfig stuff). This happened to at least 5 different production servers.
Sessioncluster was not enabled I don’t believe. We had changed from Application to J2E sessions a decade ago for some reason ( I can’t recall but was around the time we started slowly migrating from ACF).

1 Like

While Zac and Beau sort out his aspect of this challenge, I hope we’ll hear back from the OP @AnasC also, especially if they might reply to the several points I’d raised a couple of days ago. (I realize it’s the weekend. Not rushing you.)

While it’s certainly possible that Beau and Anas have the same problem/setup, they may may not. :slight_smile: I’m also noting this to help casual readers realize it’s two different people raising session issues here.

@Zackster
@carehart
We are using
Session Type: Application
Session Storage: Memcache ( expire time 1 hour , using object cache)
loosing session properties when session lost.

no onSessionEnd is not firing

What I found further, we are using the AWS Load Balancer and using multiple server instances , and the target group has stickiness enabled for 8 hours but the pattern that I found for logouts is.
User logged in → do some random operations, sit idle even and after random interval the sessionStart request for the same user with same CFID fired and after that the user session lost.