Inspect templates

language
1

You know we have the settings “inspect templates” in the admin under “Settings-Performance/Caching” that allows 3 states:

  • always
  • once
  • never

Same setting also can be defined with every single mapping.

For a live server normally we should have this setting on “never” as long the server does not produce cfm templates (and even if so we could do a mapping for that section and set that section to “once” or “always”).

Problem is that we have to flush manually the template cache when we publish new code, now i have 2 ideas for this.

  1. an event gateway that looks or changes in code a flushes automatically the template cache if necessary
  2. a way to trigger that the template cache get flushed as part of your deployment process

What do you think about this?

2

I prefer a way to trigger the flush. currently in my applications I have something like this in Application.onApplicationStart():

if (Request.isDebugIP() && URL.keyExists("flushCodeTemplates")
    pagePoolClear();

this way whenever I want to clear the page pool I add a URL parameter and make the request from a known debug IP.

problem is that this flushes all of the code templates. it’d be great if I could to it for specific templates only, e.g.

   pagePoolClear( [ getCurrentTemplatePath(), "included1.cfml" ] );

FWIW: I’ve never used the always setting. I’ve never had to re-compile the template more than once in the same request.

3

I like the idea of being able to do being able to flush the queue when it is needed. As a side note are these settings defaulted to what is best practice for a production box?

4

the default setting is once, which is not as good as never for production, but if you have never as the default setting then no one would understand why their code changes don’t take effect.

on one of my production servers setting to once vs never costs about 0.5ms per request, which I can live with while developing/updating many templates.

5

I would like to trigger outsite the code, question is how do people update the code?

6

Flushing particular templates from the cache could be a nice feature, it would definitely help for those cases where someone has had to flush the entire template cache while a server is under some load :slight_smile:

Beyond that I think the community should be building the tooling around the available features rather than building it into the language/engine (i.e. the community could build an event gateway or tool used during deployment, I’m not sure it needs to be part of Lucee).

For me the ideal deployment has inspect templates set to “never”, and when you are deploying new code you spin up a new instance/container and throw the old one away!

3 Likes
7

After deployment, unless we have only deployed some view files, we reload the application which invokes specific reload logic (in which template flushing can be invoked).

8

I have also platforms like heroku in mind.

9

With Heroku when you redeploy you are working with a non persistent file system locally. So effectively

1 instance running
Deploy code
New instance gets spun up with new deployed code base
Load balancer gets told to route request to new instance
Old instance dies

So this feature really doesn’t apply to those types of deployments

1 Like
10

Given that all modern devops approaches to deployment involve ephemeral servers, including more opinionated PaaS like Heroku, it would be great to see some specific options for deployment related admin settings available through environment variables.

For example, it would be ideal to have options to have all ephemeral deployments with the code base set to NEVER. And to not deploy the Lucee Admin at all. I’m sure that must be possible somehow today through one XML config tweak or other, but scripted provisioning would be a whole lot easier, and less prone to breakage, if this was something that could be configured through environment variables.

For server environments that are more permanent, we always deploy via version control; for example, git pull. While I’m sure they exist, we don’t have any systems that dynamically generate .cfm templates on the server as part of the apps operational use.

1 Like
11

In Lucee 5 the admin is moved to an extension (available by the local e tension provider).

12

currently when Lucee starts up and there is no web/server.xml config files – the web/server-config xml files are deployed from within the Lucee archive, which has the default settings as set in the source code. that happens when you run Lucee for the first time after deployment.

it should be very simple to add an environment variable, e.g. lucee.config.default, as you suggested that will point to a different xml file if the config file does not exist.

2 Likes