In part one, I set the stage for the series with a lot of important introductory points and other resources. Now let’s move on to the first category of things I regard as hidden gems.

Installation gems

I do realize that many readers here are developers rather than administrators, but even so, many developers do still install their own copy of CF, especially the free Developer edition. (For more on the editions of CF that are available, see my post, CF install/deployment choices: what’s right for me?)

32-bit CF installers no longer offered

I have just one “gem” to share regarding installation, and it’s not so much a feature but rather a warning to some: as of CF2018, note that there is no longer a 32-bit installer for CF. For more, see this Adobe blog post.

Administration gems

Whether you’ve installed CF or someone else has, you may be responsible for administering it. Let’s take a look at some perhaps “hidden gems” regarding the CF Admin.

New CF Administrator UI

First up, there’s a pretty major change in the CF Administrator user interface. Instead of the long list of expandable sections down the left that we’ve had since the earliest releases, there’s now just the section headings on the left. When you click on one, the names of the pages/links within that section are shown across the top of the page.

Note that the hamburger menu at the top left (above the sections) will toggle whether you see the section names AND icons or just the section icons. And note also that when it does show the icons only, you can mouse over them to see their names. For more about the change in the Admin UI, see this Adobe blog post on the change.

New “search” option in CF Admin

Perhaps you’d already found the new UI and the features to control and understand the section names, but you may have struggled still to find some particular admin page or feature. We used to see all the sections and pages down the left, now we ONLY see the pages across the top when viewing a single section chosen on the left. That has confused many long-time users.

Here’s very goods news, and perhaps the first true “hidden gem” (if you’d not yet found it): see the search feature offered at the top right. Click the icon and type a few letters of the feature you seek, and a popup will show the pages that refer to that phrase, which you can click to go to the respective page. (For instance, type <code>ssl</code> to see what pages in the CF Admin have reference to SSL.)

New option to pause/resume all scheduled tasks

Here’s another potential true “hidden gem”, a change in the scheduled tasks page that you might easily miss: CF2018 finally adds new buttons to “pause all” and “resume all” tasks. We have long able to pause each task individually there, but a real benefit of this ability to pause ALL of them is when you may realize that there’s a problem with having all listed tasks running.

For example, you may have imported all the Admin settings from some other instance, such as using the Admin ColdFusion Archive/CAR feature, or by the import wizard that runs after the installer to import all settings from an older instance that existed on the machine. Or with the Enterprise (or Developer) edition, you may have defined tasks in the main cfusion instance and then found that when you created a new instance, it built the new instance using the admin settings of the cfusion instance.

In all these cases, you may want to stop all the tasks because they duplicate the tasks from the other instance. Now you can.

Some may know that the CFSCHEDULE tag itself has long been able to pause all tasks, with ACTION=”PAUSEALL”, at least since CF10. It’s just that the CF Admin task page did not offer this. As for the tag-based pause, note that in CF2018, the tag no longer requires use of the GROUP or MODE attributes for the “PAUSEALL” action. Without these, it will only stop “Server” mode tasks, and “application” mode tasks in same app where the CFSCHEDULE tag is running. For more, see the online help for CFSCHEDULE.

New Caching options

The last gem (or perhaps less-known change in 2018) related to CF administration is the sort of change that really extends beyond merely administration, to possibly benefit to developers and site users, and it relates to new cache storage options.

As you may know, since CF9 ColdFusion has relied upon ehCache to be what provided the underlying cache storage engine for various caching features in CF (whether with tags and functions specifically storing and retrieving from cache, or for features like query caching, etc.) But some people have long wished they could use an alternative caching storage engine, such as Redis or memcached.

One reason they may have wanted to use those alternatives was to be able to run the caching out of process, or to distribute the caching over multiple machines. The ehCache within CF was deployed by default as an in-process cache, meaning it runs within the CF process (using its heap). Adn while it was technically possible to tweak the ehcache.xml file within CF to point to it running out of process or as may be configured on another machine, there was no provision for that in the Admin or application settings, so most folks never even considered the possibility.

CF2018 addresses these limitations by allowing you first to optionally change which caching engine CF should use: ehcache (still the default), Redis, memcached, and JCS (Java Caching System, which like ehCache is implemented in CF as an in-process caching option).

This change can be made in the CF Admin Caching page, or at the application level (via attributes of cfapplication or properties of application.cfc). There are also new AdminAPI methods related to the new caching options.

A final note related to this: in the ColdFusion 2018 Standard edition, only ehCache and JCS are offered. The two distributed options, Redis and memcached, are offered only in the Enterprise (or trial or Developer) edition of CF. (This is in fact the only new feature in CF2018 that is unique to the Enterprise edition, it seems. There remain of course many other features that are Enterprise-only. That’s fodder for another blog post.)

That said, just as it’s possible to manually configure ehcache to work in a distributed fashion, it’s also possible to do the same for JCS by editing its configuration file within CF, called cache.ccf. And like the ehcache.xml file, it’s stored in the [cf2018]/cfusion/lib folder. See the JCS docs for more on doing that.

And for more information on the new caching options, see the Adobe blog post introducing the new caching features, especially a useful table at the bottom, and the CF docs on the caching enhancements.

Configuration gems

Leaving the CF Administrator now, the end of that previous point showed that there are options for configuring aspects of CF which are managed outside of the administrator. And as with many releases, there are some hidden gems regarding such configuration. This section will focus first on changes related to configuration of the CF web server connector, then about changes related to the configuration of Java underlying CF.

Web server configuration

Before delving into thew new (and perhaps hidden) aspects of web server configuration, let me offer some background that may benefit some readers.

In order for ColdFusion to integrate with (be fronted by) an external web server like IIS or Apache, you need to create (or can remove or configure) such a web server connection using the CF Web Server Configuration (or wsconfig) tool. And with the change of CF10 to run on Tomcat (versus JRun as CF6-9 had run upon), there were some important changes in how the web server configuration worked (especially in terms of the underlying files related to them). Full discussion of the changes and impacts regarding web server configuration changes since CF10 is outside the scope of this blog post.

But there were important aspects of a possible need of “tuning” that Tomcat-based connector and CF web server configuration, at least for some sites and traffic loads/patterns. There have been Adobe blog posts on such tuning, most recently this one from the CF11 era, whose suggestions mostly apply still in CF2018. FWIW, there were important changes in CF2016 that offered much better defaults than CF10 and 11 (CF2016 and above is better suited out of the box for a 2-site configuration), and there were also enhancements in CF2016 for the configurable options in the wsconfig tool. These too (and general use of the wsconfig tool) are beyond the scope of this post to elaborate on, but note that they do carry into CF2018.

Still, I bring all this up to to point out a possible hidden gem in CF2018 regarding yet another enhancement in web server configuration, as shown in the wsconfig UI. Notice that if you click the “advanced options” while configuring a connector, there’s a new set of “load levels” which which one can choose:

These choices are directly related to the kind of configurability discussed in the aforementioned Adobe blog post on IIS tuning (which apply also to Apache, by the way), and the new UI feature simply offers an option to easily select a configuration based on your expected “load”.

Now, these “load levels” are a somewhat arbitrary set of pre-configured values. It’s not going to be readily obvious from their names or the values shown as to which level is “right” for you. There’s certainly more intelligence required, including your own assessment of the sort of information presented in the Adobe connector tuning blog post, as well as evaluation of how your site performs.

And there are various ways that the web connector performance and its available metrics could be assessed. Traditionally (since CF10), the primary means to monitor the connector has been the Tomcat “status worker”, an optional monitor UI that could be configured for each connector. Adobe has done a blog post on setting up the status worker, and then I did a subsequent post elaborating on setting up and using this “status worker” monitor.

At this point, some of you may be thinking, “why can’t CF just figure out the best settings for me, based on its own assessment of my traffic?”, and you’re in luck, because CF2018 has added a feature that asserts to do just that, along with providing still better monitoring of the connector, discussed next.

Connector auto-tuning feature, within PMT

I mentioned in part 1 of this series that one of the major new features in CF2018 is its new built-in (optional) performance monitor, called the Performance Monitoring Toolset, or PMT. I’ll have more to say about the PMT in general, in part 3 of this series.

But among the many (many) features provided within the PMT is a new feature to auto-tune the web server connector.

I’ll share in a moment resources with more on what those settings mean and how the feature works.

The PMT also adds a feature to monitor the web server connector:

Still another related hidden gem is a feature to also alert when the connector is exceptionally busy (when the ratio of busy to total connections exceeds a specified ratio):

For more on these various connector-related auto-tuning, monitoring, and alerting features within the new CF2018 PMT, see Adobe’s Adobe’s blog post on PMT’s connector tuning, as well as Adobe’s documentation on the PMT connector tuning.

All that said, one bummer/gotcha is that the auto-connector tuning aspect of this feature is that it only works with IIS (not Apache). But the monitoring and alerting is still useful for those connecting to CF using Apache as the web server.

Another gotcha is that while the auto-tuning feature does tweak the connection pool size and such settings managed in the workers.properties file (see the posts and docs above for more on that), it does not also tweak the maxthreads value in the server.xml file. This is indeed mentioned in passing in the Adobe posts and docs above.

Still, be sure to take advantage of the benefits that these new features do offer.

Java-related config changes

As we wrap up, the final set of configuration-related matters one might class as “hidden gems” are related to the Java version and configuration underlying CF2018.

As many readers will know, CF runs atop Java (CFML code is actually compiled into Java classes), and the typical server deployment of CF comes pre-configured running atop Tomcat, and with an embedded Java engine that CF implements. Of course, we are also free (and encouraged) to update that JVM, for security reasons and to get bug fixes, to keep it on the latest available point release of whatever JVM version CF supports. That can get a bit confusing for some, and it leads to the first point about Java-related configuration changes.

Changing CF support, from Java 10 to Java 11

As of the initial release in July 2018, CF2018 came out with an embedded Java 10, and it did (and as of this writing still does) only support THAT version–not Java 11, which came out in October 2018.

Some readers will recognize that this is a problem, as Java 10 is what Oracle calls a short-term release. Indeed, it was released in 2018 and is no longer supported after 2018. That’s REALLY “short-term”, right? (I’ll have more on this notion of short- versus long-term Oracle Java releases, in a moment.)

So CF2018 users are in limbo currently, since they cannot update Java 10 beyond its last version, 10.0.2, and they cannot (as of this writing) update to Java 11. (As for CF2016, that currently runs on Java 8, and they have a similar problem in that updates to that will no longer be offered publicly, for free for production use, after January 2019.)

The first good piece of news on this front is that Adobe has just announced last week that they DO indeed plan to support Java 11, for both CF2018 and 2016. Expect an update to both releases, adding that Java 11 support, in February 2019. (Sadly, Adobe does not plan to update CF11 to run on Java 11, even though support for CF11 doesn’t end until April of this year.) For more on this planned Java 11 support for CF, see Adobe’s Jan 2019 blog post. You can also offer there comment and questions to Adobe about the timing of things, the lack of a planned update to support Java 11 in CF11, and so on.

Adobe licensing Java 11 and Java 8 updates, for production use with CF

You may have caught that I mentioned in passing above that Oracle would no longer allow free access to updates to Java 8 (for production use). That was a change announced mid-2018. They also announced then that they would not allow production use of Java 11 without it being licensed (paid for). Both of those are dramatic changes for Java, going forward. More on that in a moment.

Again, fortunately both problems are solved for us, in that Adobe’s aforementioned announcement indicates that they have licensed Oracle Java for use with ColdFusion, so that users of CF2016 and 2018 will not need to pay Oracle to run CF on Java 11 (when its support is added) or for Java 8 updates beyond Jan 2019 (for those on CF2016).

For more on this matter of Oracle’s changes in 2018 regarding licensing of Java 8 updates and use of Java 11 in production, see a set of blog posts I did, the introducing the problem (written in late 2018, and since updated per Adobe’s announcement), as well as others to follow I did such as one on Oracle’s definition of production use, and another I did about on an openJDK alternative, Amazon Corretto. To be clear though, Adobe’s Jan 2019 announcement indicates that they will not be supporting any OpenJDK alternatives, now that they have licensed Java 11 for CF use.

Finally, if you may be interested to know more about these short-lived, “short-term” Java versions (9 and 10), I had also done a blog post on this in May 2019, which gives perspective to the challenge we have faced as these Java versions came and went, though it is again becoming less pertinent with Adobe’s planned support of Java 11. Still, people often ask, “how the heck did things jump from Java 8 to 11”, so the info if provided.

Does CF2018 use the G1 garbage collector by default? Not currently

The last point I’ll make in this part 2 post is not so much a change that has taken place in CF2018 but rather one that has not, despite what some are saying. I have heard various mentions in the community (and from Adobe presenters at CF conferences) that CF2018 is by default running Java’s more advanced G1 (or “garbage-first”) garbage collector. That is not the case, and it seems to be a misstatement.

You will find that if you look at the CF2018 CF Admin “Java and JVM” page (or the jvm.config file which that page controls) that CF still shows use of the -XX:+UseParallelGC jvm argument, which indicates that it still uses the Parallel GC, at least as CF2018 was released initially (and also as of its update 1).

What is true is that Java 9 and above (not to be confused with CF9, to be clear) DOES use the G1 GC by default, if you don’t specify any GC arguments. So yes, if that UseParallelGC arg was REMOVED from CF’s java args in CF2018, then the Java underlying CF2018 WOULD use the G1 GC algorithm. (Since CF2016 and below did not support Java 9 or 10, we would not for now experience this same possibility if we removed that JVM arg in CF2016 or below.)

I don’t know whether it really is intentional by Adobe (or not) that CF 2018 still specifies that UseParallelGC argument. Since they are mentioning the benefits of the G1GC in some presentations, the implication is indeed that it is supported and perhaps even recommended, though I have found no specific document indicating that either way (whether we should or should not use it). Time will tell, I suppose.

I can point out that at least one blog post on the Adobe CF portal which does also discuss the benefits of the G1GC, by Carl Meyer (not of Adobe). And if you may want to know more about the G1GC in general, see Oracle’s docs on it.

So that’s that it for hidden gems in CF2018, regarding installation, administration, and configuration. I hope you may be excited about some of the things discussed.. Comments and questions are welcome, and share word of the posts to spread the word (indeed spread the word about the CF portal).

In part 3, we will cover some hidden gems regarding security (including the new Auto Lockdown tool), as well as performance (of CF in general) and the Performance Monitoring Toolset (PMT), in particular. And of course there remain still many more topics we will explore in subsequent parts. See part 1 for the list of topic areas we will explore in weeks to come.