@Daniel Mejia It doesn't. The application timeout is defined in the cfadmin or in your application code ... this.applicationTimeout = createtimespan (..). Now, in order to get around this, I put some code in the 'onRequestStart()' that says

if ( structKeyExists(url, 'reload') )
{
    // Lock the scope
    lock scope='application' type='exclusive' timeout=10
    {
       // Call onApplicationStart() to reload
       onApplicationStart();
    }
}

I forget that applicationtimeout is also a global setting, which I have learned is by default 2 days. Thank you.

Your welcome but I would also put the code in the onRequestStart() which gives you real flexibly if you make changes to the application.cfc and really can't re-start the application. This will allow you to make changes and have them put into place without restarting the application. This is just my opinion.

Elaborating a bit on Drew's response above: your application's onApplicationStart() method will be executed on the first request to the application after the server is started. If there are no requests within the application timeout timespan (e.g,. 2 days or whatever it is set at) the server will stop the application (you can see that in the server logs), and it will run the onApplicationStart() again on the next request to your application. Each request to the application resets the clock on timing out your application (i.e., as long as your application is receiving requests, it will never timeout). What Drew is providing is a manual way to force an application "restart".

the restart is something I have in almost all my cf applications.

Caveat: https://blog.adamcameron.me/2012/07/difference-between-events-and-event.html

@rstewart that is interesting. I never knew that. I always thought it timed out regardless of the requests made within that time frame and restarted on the first request after onApplicationEnd().

Pretending

onApplicationStart

causes the application to restart is... mostly OK. However it's a bit of an inelegant way to do it. Better to stop the application and let it restart when it's ready. The difference is that simply calling

onApplicationStart

will pull the rug out of any currently running requests, which will leave yer application in an unstable state.

@Adam Cameron’s last point there is an important one: in a busy app, you want to be very judicious in going back through that initialization logic. depending on what you're doing and how long it can take...

SO technically I could just

private void function reset(){
   application.uniqueid = createUUID();
}
public boolean function onRequestStart(string targetPage){
   if( structKeyExists(url,"reset") {
      reset();
   }
}

Yes, if that's the only application-scope variable you need to reset... but I'd make sure to lock the scope in doing it.

For sure stewart. Fundamentally, I learned that there is a default global timeout for applications, onApplicaitonStart() is just an event handler. Application will not timeout ever if within the time frame there is a continuous request made. Thank you fellas.

I sincerely just dont have the time to test this myself - right now... Does anyone know how Lucee (current) behaves with ApplicationStop()? In that does it allow current requests to finish successfully? Thanks.

@gavinbaumanis We encountered this while migrating a large app from ACF 2016 to Lucee. If a request executes

ApplicationStop()

and later tries to use something like e.g. an application variable. The same for other requests that had already started when

ApplicationStop()

was executed as well, IIRC.

That would seem reasonable wouldn;t it? Don't expect an application scoped variable to exist after an applicationStop() has been called in THIS request. My question, sorry if it wasn't clear - was that in ACF - depending on patch version; • You have XX requests already running. • You call applicationStop() from a separate request (I have JUST that in a CFM

<cfscript>
applicationStop()
</cfscript>

is the applicationStop() queued BEHIND existing requests - allowing them to finish correctly. OR does it effect running requests - causing them to lose their APPLICATION settings / vars / etc?

@gavinbaumanis I tested this on CF2021 and Lucee (current docker version).

applicationStop

does not interfere with any other already-running requests on CF (ie: they run to completion with the application instance they started with). On Lucee they break. Off out to sit in the sun with beer and music right now. Will tidy up my code and post here later (maybe tomorrow)

Thanks very much Adam! I do really appreciate it.