Don't miss that Adobe had added a useful feature (a "patch", made available in Apr 2024) to help in identifying any CFML code you may have which refers "implicitly" to scopes that would no longer searched (for any variables without a scope prefix), which is the new default behavior for CF2021, CF2023 and beyond as of the March 2024 updates (updates 13 and 7, respectively).

TLDR; (more on each of these points, in the rest of this post)

• For more on the update and the change regarding searchimplicitscopes, see my blog post on the March update
• By following the simple couple of steps (including downloading a needed "patch" as discussed and linked to below), CF will start logging (to a new unscoped.log) whenever code is run that would access an unscoped variable when that would cause CF to implicitly search through scopes (external to the request) which it would no longer search if "searchimplicitscopes" was false. (To be clear, the new logging only works if searchimplicitscopes is true, otherwise such searching would fail if searchimplicitscopes is false, as is the new default as of the March 2024 updates)
• The "patch" is a jar which you must manually obtain and put into place--it is NOT included with the March 2024 CF update, or any others. The steps are very simple, discussed below or in an Adobe technote that was released in the weeks after the March updates, with the title: View unscoped variables in a log file
• Note that this patch is also NOT included in the June 2024 CF updates, CF2021 update 14 and CF2023 update 8
• Further, beware that if you DO apply any update to CF after applying this patch, that update will REMOVE this "patch" (and any jars in the lib/updates folder which is referred to in the technote). Therefore, you would need to put the jar BACK in manually after any such CF update, for it to continue doing its logging
• Finally, FWIW, note that you can even leverage this patch in the CF two updates PRIOR to the March 2024 updates which introduced the change in the default for searchimplicitscopes, so updates 5/6 and 11/12, respectively. That means someone could also use this patch to test BEFORE moving to either the March 2024 updates or later

Again, more on each of these points below. But for some, the news and the link to the technote (and my couple of tips above) may be all they feel they need to hear. For others, I think more perspective may help, so read on for that.

[....Continue Reading....]

As of the Oct 2022 CF updates (CF2021 update 5 and CF2018 update 15), Adobe has chosen to remove the CF Admin feature to view, search, download, and delete CF logs, due to asserted (but as-yet undocumented) security concerns.

What if you want it back? In this post, I explain what changed, why, and how to get the functionality back--albeit at your own risk. For more, read on.

[....Continue Reading....]

Note: This blog post is from 2022. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

The FusionReactor folks will offer a webinar this Thurs, Mar 24, at noon US Eastern, "Introducing Distributed tracing and on-prem observability".

I highly recommend that FusionReactor users (and others) register. (Even if you can't attend, you will get access to the recording.) It's about some totally new capabilities:

• Note that it's about changes coming in both the FR Cloud and in the traditional "on-prem" FR UI. As such, the new capabilities should be very compelling even for those FR users who have not yet bothered to (or for some reason cannot ) use FR Cloud
• Also, it's about more than what's been made available yet to those beta testing the new "logging" feature in FR Cloud
• Finally, for those who DO use FR Cloud, there may be discussion of upcoming changes regarding the FR Cloud UI itself

[....Continue Reading....]

Note: This blog post is from 2019. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

If your server is behind a load balancer or other sort of proxy, you may have noticed that when you view information about requests in FusionReactor, they all have the same (or nearly the same) IP address. This can be easily fixed, and I show you how in this post.

[....Continue Reading....]

Note: This blog post is from 2016. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

I'd like to take a diversion from my recent posts focused on CF2016 and talk about something that applies (and should interest) anyone using CF 10, 11, or 2016.

Have you heard of the new "metrics log" option that was enabled in CF10? If you have not, it's worth knowing about (there's precious little documentation, and I'll point to it, and give you still more info to help you use it). It's a useful, low-impact mechanism to get some high-level metrics logged by CF every 60 seconds (by default), and stored along with other CF logs.

If you did know about it, you've probably had some problems with it. Why does it show "nulls"? What do reported metrics really mean? Why do they not jive with what I'd expect to be the numbers reported?

In this post, and a Part 2 to come, I will introduce the metrics log, pointing out some key things you need to know to have it setup to work at all, and then I'll share my observations of things I've come to understand about the reported metrics.

[....Continue Reading....]

Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Following on my earlier entry, CF911: Lies, Damned Lies, and CF Request Timeouts...What You May Not Realize, another common source of confusion and misunderstanding for people is when they think their server is "running out of memory", when in fact the problem is often not at all what they think. In this entry, I want to apply the same "cranky" tone :-) and extended explanation to this equally controversial/confusing topic.

I hear people raise concerns with memory problems quite often, whether in my CF Server Troubleshooting practice, or just in my participating in many mailing lists. Indeed, addressing this issue more than a few times the past couple of weeks has motivated me to create this, which will be a series of blog entries.

The series parts are expected to be:

• Step 1: Determine if indeed you are getting "outofmemory" errors (this entry)
• Step 2: Realize that having high memory usage is not necessarily a problem (entry to come)
• Step 3: Realize that OutOfMemory does not necessarily mean "out of heap" (entry to come)
• Step 4: Diagnose why you really are running out of heap (if you are) (entry to come)
• Step 5: Realize that CF is maybe suffering because you set the heap too large (entry to come)
• Step 6: If CF is hanging up but NOT due to memory, what could it be? (entry to come)

Let's get started and see how far we get...

[....Continue Reading....]

Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

As a CF user or administrator running CF 6-9 on Windows, have you ever wondered how to increase the size of the console logs (-out log files in the [cf]\runtime\logs directory, or [jrun]\logs in Multiserver)? This entry will tell you how. It's quite easy to do, but it's not done using usual log file size control settings in CF's Admin or XML files.

The quick answer is to use either of two approaches: either the jrunsvc.exe in CF's runtime\bin (or [jrun]\bin), or do a manual registry tweak, both of which I show below.

Update for CF10, forward: CF10 and above change to using a new set of xml entries in the neo-logging.xml file, called maxOutLogSize and maxOutFileBackup that should control this (and which should not to be confused with the long-existing maxFileSize and maxFileBackup, both of which correspond to the settings on the CF Admin logging Settings page.) That said, some users had found in the early updates of CF2016 that somehow the xml entries were NOT being honored. It's not clear from them if later updates did fix that problem. I've not heard it as a widely-reported one.

BTW, if you don't know what CF's -out*.log files are about (they're important!), they're technically holding the console output for CF, when it's started as a Windows service. This can be vital information that is NOT logged in the normal [cf]\logs directory or Admin Log Files display. (If you start CF from the command line, then the same info is written to the command line instead and not to the log file.)

(If you're on *nix, pretty much the same info appears instead in the [cf]/logs/cfserver.log. I know some people have wondered about controlling the size of that file. What I discuss here applies only to Windows.)

Background on the sizing of the -out*.log files

[....Continue Reading....]