When using Coldfusion Sessions, FusionReactor rarely ever shows any as destroyed. The created count just seems to climb infinitely. I do have a long session time, but if the website visitor is not logged in, I delete the session at the end of each request. Here's the code from onRequestEnd:

if(isNull(session.user.id)) {
    StructClear(session);
  }

Though doing this doesn't seem to end the session. Is this the official way or is there another way in Lucee to officially destroy the session in a way that FusionReactor would recognize?

@Tim Badolato That code is not "deleting" the session. It's simply clearing all keys from the struct. Use

sessionInvalidate()

to remove it

You could perhaps benefit from reading this - https://blog.adamcameron.me/2012/07/difference-between-events-and-event.html - re the difference between events and event handlers. Clearing the session scope is just that: clearing the session scope. It has nothing to do with the user's session, other than removing the data you had associated with said session.

sessionInvalidate

might help you - https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-functions/functions-s/sessioninvalidate.html - but there are some caveats as mentioned in the docs. I think on the whole keep yer session timeout short, and on any docs that the user might naturally idle on for a long time, ping back to the server periodically to keep their session alive. Or just let it timeout and have them reauthenticate and take them back to the same URL afterwards. Don't forget the sessiontimeout resets every request. Often ppl don't need as long a session timeout as they might think

I would recommend a shorter timeout. The session will stay alive so long as there is activity by that user.

haha, @bdw429s... snap.

Also, check out external sessions stored in a cache or a DB. Lucee makes this pretty easy and • they persist across CF restarts • are shared between servers • don't consume as much heap

Thanks Brad/Adam! I had no idea about sessionInvalidate

See also:

applicationStop

instead of calling

onApplicationStart

, thinking that has anything to do with restarting the application. Another thing that ppl often get confused about.

Wouldn't this require constantly hitting the DB?

Not necessarily. It depends on whether you set

sessionCluster

to true or false 🙂

Yeah I'd consider it premature optimisation to worry about it before testing. But def good to flag it up as a consideration though. So, like, do test it.

Using

sessionInvalidate

in production but I'm still not seeing any destroyed sessions. 🤔

Are you logging something in

onSessionEnd

so as to gauge how many destroyed sessions you'd be expecting to see?

sessionInvalidate

doesn't seem to be triggering

onSessionEnd

That's too bad. A peek at the bug tracker reveals these two related tickets: https://luceeserver.atlassian.net/browse/LDEV-4166 https://luceeserver.atlassian.net/browse/LDEV-3248

Is this why FusionReactor isn't tracking destroyed sessions?

¯\_(ツ)_/¯

Yeah just tested on Lucee and

sessionInvalidate

doesn't work. It... erm... does... on CF. Sorry for the bum steer there Tim.

All good! Glad it's not just me 😅

Do try the timeout=0 trick. You should be able to conditionally do

this.sessionTimeout=0;

in

Application.cfc

OR

application action="update" sessionTimeout=0;

anywhere in your code. (which despite its appearance, will only affect the current request) And like Zac said in the channel, Lucee clears dead scopes async after a minute or so.

setting the

sessiontimeout

to

0

has odd behaviour on Lucee. I'm passing a URL param

sessionTimeoutSeconds

which I use thus:

this.sessionTimeout = createTimespan(0, 0, 0, URL.sessionTimeoutSeconds)

I then make a request with that as default, then one with that

0

, and then a third with default. The first req starts a session. The third req starts a new session, and

onSessionEnd

is only ever called for that second session (identifying different sessions via

sessionId

). The session end doesn't seem to respect the timeout. I've run it a coupla times, and it seems to be called "within a minute" of when it was supposed to run.

Yeah, it's part of the controller thread

This behaviour is not accurately documented (https://docs.lucee.org/guides/cookbooks/application-context-basic.html#onsessionend).

One rather oddball part of that is when the session is created, Lucee stores the actual Application.cfc instance along with the session to call the

onSessionEnd()

method later since that happens outside of any web context

If I knew the correct jargon to use I'd update it, but... only got the vernacular version from you, so will leave it.

Seems ok to me

done.

I've assumed it was because the controller thread didn't have the information needed to know how to create the CFC later. I mean, it seems like that would be possible, and even easy, but what do I know.

👀

The thing about it that bit my client was that ALL VARIABLES from the app cfc's pseudoconstructor were kept in memory forever.

shit so... if like using

onRequest

then that could be a fuck-load of variables?

Potentially, yes

that ain't good.

I'm fairly sure 5.3.7 was simply the version my client was on. I assume Lucee's done that prior as well

gotcha

Am I right that none of this happens in reasonably current ACF? It's a Lucee-only entertainment? And once again gents, much appreciation for the digging and grokking. You keep the whole thing spinning:

CF behaved as I would expect with

sessionInvalidate

.

I had an ave of about 50k sessions largely from bots until recently. I added something like this in app.cfc pseudo constructor. Setting it to zero didn't work for me

if ( (variables.browserInfo.isBot)  &&! variables.sentCookie ) {this.sessionTimeout = createTimespan(0,0,0,5);