[Looking for Charlie's main web site?]

CFMyths: "If/when I apply Cumulative Hotfixes, I need apply only the latest CHF, right?"

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.
This is the second post in my planned CFMyths series. In the first, I addressed the myth that "When I download CF to install it from scratch, it has the latest fixes/updaters".

Here's the next, related, myth:

True or False: "If/when I apply Cumulative Hotfixes, I need apply only the latest CHF, right?"

For instance, let's say you're currently running CF 9 update 1 or CF 8.0.1 and discover (perhaps due to my last blog entry) that you had never applied any of their associated CHFs. It would seem you should just be able to apply the latest CHF and not bother with anything related to the previous ones, right?

Answer: Well, yes and no.

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

CFMyths: "When I download CF to install it from scratch, it has the latest fixes/updaters"

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.
Today I'm starting a new series on CFMyths, some common misconceptions that I find myself often helping correct on lists/forums or with my troubleshooting customers.

First myth up for consideration:

True or false: "If/when I download CF to install it from scratch, the installer has all the latest fixes (updaters, at least)"

Answer: False (generally). For instance, if you download CF9 today (Dec 2010), you still get CF 9.0, released originally in Oct 2009. You don't get the latest updater (9.0.1 as of this writing, released July 2010), though its existence is at least mentioned on the page, nor of course does it then include any hotfixes or cumulative hotfixes.

Why not, you may wonder? I'll explain more in a moment, along with more about hotfixes and updaters as concepts (and where to find them specifically, for each CF release).

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

I'm participating in Ray Camden's "Uber Panel of ColdFusion Awesomeness" tomorrow (Wednesday)

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.
If you've not heard about it, Ray Camden is organizing what he's calling the "Uber Panel of ColdFusion Awesomeness". :-) And I'm delighted to have been asked to join the esteemed panel.

It will be held tomorrow (or today, depending on when/where you read this), Wednesday Dec 8 at 12pm US ET (GMT-5). It's an online session, held at:

http://experts.adobeconnect.com/ubercfpanel/

And yes, it will be recorded (by Ray--keep an eye on his blog for more info, if you can't attend.)

To find out more, such as who else is on it, check out Ray's entry with more detail:

http://www.raymondcamden.com/index.cfm/2010/12/3/Reminder--Uber-Panel-of-ColdFusion-Awesomeness

BTW, for those looking for the subsequent parts to my previously started series on solving memory-related errors, my apologies. I got sidetracked with travel. Will explain when I do part 2, which I hope to get posted very soon.

CF911: Lies, damned lies, and when memory problems not be at all what they seem, Part 1

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)

Common refrains about memory issues

The common complaints about memory issues (and my quick responses, to give you a sense of where I'll be going in this series) are:

  • "CF is crashing. Is it running out of memory?" (there's a log that could/should prove that, and that's what we'll discuss in this part)
  • "CF's use of memory is high" (which may not be a problem. If you're looking at memory from the OS perspective, it may not matter as much as heap use within CF. This will be covered in part 2)
  • "CF's use of heap memory is high" (to which you'd think, "ah, well that's got to be a problem, right?", but no, not necessarily, as I'll explain in part 3)
  • "CF has a memory leak" (to which I'd retort, no, generally, it does not. There's nearly always some other explanation. We'll cover that among things in part 4)
  • "CF is running at 100% CPU before it crashes" (this could be related to memory problems, and more a consequence rather than a cause, or it could be entirely unrelated to memory issues. See part 5)
  • "CF is crashing all the time" (well, is it really crashing, or just hanging up and not responding? That's not a good thing, but it's very different from it crashing on its own. See part 6)

So what if we really are suffering a problem?

I'm not saying there's never a real problem of really "running out of memory". It's just that often things are not at all what they seem (or what most presume them to be, from my experience helping people), and that's going to be the bulk of what I'll talk about in this series. But what if your server is really crashing (or simply not responding), and you think/swear/know that it's a memory problem....

What should you do? Increase the heap size? Increase the permspace? Change the GC algorithm?

Sacrifice a chicken?

I'd say, none of them (though if you're in a rural setting, then perhaps cooking and eating the chicken might help settle your blood sugar so you can stay calm). Really, I know that goes against conventional wisdom, which seems always to suggest diving into the JVM settings. I'd say "hold on there, pardner."

Step 1: Determine if indeed you are getting "outofmemory" errors

This is one that surprisingly few people consider when faced with their server crashing or not responding. They go with whatever conveys to them a sense of there being a memory problem, perhaps adding their own experience or what they read, and they start chasing solutions.

I can't tell you how often I hear people lament that they've googled and found all manner of conflicting and confusing recommendations. And it doesn't help at all that they may be running on CF 8 or 9 (with Java 1.6) while reading about a "solution" written in the time of CF 6 or 7, when it ran on Java 1.4. Of course, the writer often won't have thought ahead to clarify that.

Instead, I'm saying, "stop, drop, and roll".

"Stop" the tail-chasing, "drop" into the pertinent logs directory in CF, and "roll" through them looking for an occurrence of "outofmemory".

Look first in the Console/Runtime/JRun logs

Let me be more explicit: the logs you want to look at for these outofmemory errors are NOT (necessarily) the ones you see in the CF Admin Log Files page. Those are the [cf]\logs directory (or are buried deep within an instance on Multiserver).

Instead, you want to see the "console" or "runtime" logs. Where those are depends on how you are running CF:

  • If you're running CF from the console, then look at the console display of logging info. (And if you started CF within CFBuilder, and did not set it to start as a Windows Service, then look in the console view of CFB for this info.)
  • If on Linux, look at the cfserver.log in the main CF logs directory.
  • If on Windows, running CF as a service, look instead at the -out.logs, found in the [cf]\runtime\logs directory (or [jrun]\logs on Multiserver, in which case there will be a prefix for each instance name in the log file names). You can generally ignore the -event logs there, as they typically just have a subset of what's in the -out logs. (Update for CF10: these logs ARE in fact now in the same directory as other CF logs.)

Some refer to these as the runtime logs, or the jrun logs, or perhaps the jvm or console logs. Whatever you may call them, their location is above and the explanation of their value follow will become clear n this series of posts.

Bonus topic: you can increase the max log size

(I will note that the way these -out.log files work, by default, in CF9 and before is that they fill at 200k increments. Yep, not 200mb, but 200kb!, and you may blow through dozens of them in a few minutes if things are going nuts. That size is configurable, but not through means you'd normally expect. See the blog entry I recently published, CF911: How to control the size of CF's -out.logs.)

Look next in the hotspot/pid/jvm abort logs

Separately, there are some other potentially important logs that may relate info concerning memory problems: what some call the "pid", "hotspot", or jvm abort logs. The filename is in a form like hs_err_pidnnnn.log, with some number in place of the n's.

These logs are found in a very unexpected place (for logs): in the directory where CF stores the jvm.config. So on Standard/Server deployments, that's [cf]\runtime\bin. For Multiserver, that's [jrun]\bin. (As of CF10, it's in the [cf10]\cfusion\bin, or the [cf10]\instance\bin for multiple instances.)

Look in that folder for any .log files. There would be one such "pid" log for each time that the jvm "crashes" due to certain kinds of problems. It could be a crash in the hotspot compiler, in hotspot compiled code, or in native code. (To be clear, many "crashes" of CF are not of the sort that will create such logs, so again, it's only certain kinds of crashes that will lead to them.)

What matters most, for this post, is that again you look at least look for such logs in this folder (occurring around the time of some crash you're interested), and if there look in the logs for any reference to the phrase "outofmemory". Of course, there may be such PID logs that don't refer to "outofmemory", but such crashes are beyond the scope of this post. And while the pid logs have lots of information in then, explaining all that is also beyond the scope of this entry.

The point here (of this section of this post) is that when you have a crash and you suspect it's a memory issue (or if you don't know the cause and want to learn more about what it may have been), you want to look in these two log directories mentioned above. Many never do, and this is part of why they end up chasing their tails, going instead on gut feelings or trying out various alternative "solutions". I say instead: find the diagnostic info, and act on it.

Searching through the log files (console or pid logs), the easy way

But rather than "look" at all these logs in these directories, one at a time, I suggest instead that you automate the process and search them (I was tempted to say "stop, drop, and mole" in my quip above, since you're "ferreting" through the logs, but that seemed a stretch.)

If you're on *nix, I don't need to give you any more info on how to search the files. Just grep it and rip it. :-)

If you're on Windows, though, you'll perhaps be tempted to think I'm referring to the built-in Windows Search tool to search the directory. I am not. Indeed, let me plead, for the sake of all things decent, please use something better. It's just not a completely reliable (or fast) tool.

I have blogged about a wonderful free alternative, called FileLocator Lite. Use that instead. (If you have another tool or editor you favor, that's fine. No need to bring that up here. I recognize those other options in the other blog entry.)

The beauty of FLL is that once installed (which is fast, itself), if you right-click on the log directory (or any directory) and choose "FileLocator Lite" from the menu, which will open the FLL UI. You can then just put the string outofmemory in the search box and hit enter (or click the "start" button in the UI). You could use *.log to the files searched, though since this directory is so small it's not critical.

In just moments it will show any found files in the lower left pane. You can sort the list by the "modified" column, to focus on files from around the time of your crash.

Then, here's the real beauty of this file search tool over others: to look inside the found file(s), you don't need to double-click the files to open them. Just single-click each file, and in the right pane it shows any lines in the found file which had the string that was searched. Brilliant, and again, a really fast way to find things.

So we're using this to find if any files in either of the folders above has any outofmemory (oom) errors. And if there are any such files, then we're looking at the occurrences of the oom errors within each log.

Don't stop at the last outofmemory error before a crash

This feature of the File Locator Lite tool, to see all the lines in the file with the given string, is especially useful in this case, because when searching for outofmemory errors, you also want to be able to quickly see the time for *all* the error messages you may find.

And you *do not* want to focus solely on the last error prior to the crash (or the slowdown, that made you want to restart CF).

(I should add that when it comes to the console logs (as opposed to the PID logs), sometimes those found oom error lines may not have a date/time stamp, to help you readily assess if the error is occurring at the time you were interested in. You may need to go ahead and open the files with an editor and search for the oom string, and then look at other nearby lines to find a timestamp.)

Once you find one (or more) preceding the time of the crash, you want to look for any occurring prior to it. It may be that the problem started several minutes before the crash (or your restarting CF). Further, it may be that the outofmemory error just prior to the crash is different from the one that started things out.

The point here is that you want to find out a) if there WERE any outofmemory errors around the time of your crash of interest, and then b) what information if any appears in the logs around that time. We'll then use that to proceed in evaluating the nature of your situation.

And of course it could be that there WERE no outofmemory errors in the logs, which would indicate that your problem was NOT likely an outofmemory error (or not a heap error after all). We would need to proceed to doing more investigation and assessment of whatever diagnostics you DO have.

Step 1 down, 5 more to go

OK, that's step 1 in determining whether memory problems are really at all what they seem. As I mentioned at the outset, the planned parts in the series are:

  • 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)

After I publish them, I'll update the lists here to link to them.

As always, I look forward to your feedback (pro, con, or indifferent).

CF911: Want to modify the CF Step Debugger's use of a random port?

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.
Here's a quick tip (and some elaboration): if you've noticed that the CF step debugger (in CF 8 or 9) causes CF to listen on a randomly changing port, you can change that behavior (assuming you have good reason to do so, such as perhaps some challenges with firewall configuration).

It's a simple JVM tweak to cause it to use a fixed port:

-DDEBUGGER_SERVER_PORT=portNumber

You can add this either in the "Java & JVM" page of the CF Admin (if in Standard or Enterprise Server), or on the java.args line in the jvm.config file (for any form of CF).

You do need to restart CF for this to take effect.

A few warnings are in order

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

CF911: How to control the size of CF's -out.logs

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 have found that these later CF versions do NOT honor either these new XML file entries OR the Registry entries discussed below.

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....]

Need to look at large files? Consider free Universal Viewer

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.
If you have any reason to look at large files (especially log files) on Windows, don't use NotePad (it doesn't like large files)! Sure, you can perhaps use WordPad, or you may be using a favored editor like TextPad, UltraEdit, NotePad++, and so on. But those are editors: they generally presume you want to change the file.

If you just want to look at a file, there's a great free tool to do it: UniversalViewer.

It can open a 1GB file as fast as a 1kb file (because it only pulls in what it needs to show the screen full of text you're looking at.) And there are times when you may well need to look at some very large files, especially when troubleshooting CF servers, like I do.

And actually, as its name implies, UniversalViwer can view far more than just text files, including images and more.

I've just only ever used it for looking at log files, for which it excels (and yes, you can search within the file, set it to tail files, and more.)

I've been touting the tool for years in classes and presentations, and I was about to mention it in another blog entry, but then I realized I'd not blogged about it on its own. Rather than have the reference lost in another blog entry, here's its moment to shine!

And yes, I do realize there are several other tools that can do this. I list this one and several others in a category of my CF411 list: Generic File View/Log Analysis Tools. (Note that there are some nifty tools in that category there for looking specifically at CSV files, as well as other entire categories for specific kinds of logs, like CF logs, web server logs, windows event logs, etc.)

CF911: Lies, Damned Lies, and CF Request Timeouts...What You May Not Realize

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.
How often have you seen (or seen others complain of getting) a CF page running longer than it's "supposed to" by a timeout you have set. Maybe you've set the CF Admin "request timeout" (first setting on first page of the Admin), or used the cfsetting requesttimeout tag or the timeout attribute on some specific tag if it's available, trying to get the request to "end" in 60 seconds, and yet you see a request running for 3 minutes, 3 hours, or 3 days! How can that happen?

Or same with if you've set the request to timeout using an alerting feature in a CF monitor like CF Enterprise server monitor, FusionReactor, or SeeFusion.

And perhaps you've seen this error from ColdFusion, in your logs or on-screen:

The request has exceeded the allowable time limit Tag: cfoutput

Do you know what this means? It's usually not what you think, and it may appear as I said 3 hours after a request was "supposed to timeout" in 60 seconds. I've even seen experienced CF developers who get thrown by this challenge. It's not new (and for those reading this even in the CF2016 era, it still happens). And it's not so much a "bug" (in either CF or the monitor tools) but just a situation that you need to understand, and there can be some ways to resolve things.

In this entry I'll try to help explain this surprisingly common problem and I hope to correct some equally common misconceptions. I'll even contend that the info in this error message is often useless and indeed misleading (and therefore the feature producing it ought not be relied upon completely, and should perhaps even be turned off for many). More important, again, there may be a way to "really" kill such a long-running request. Along the way, I'll share some things that I've not seen documented elsewhere.

I also share a solution that may work for query processing but it's NOT about a tag attribute but rather a CF Admin setting in the datasource "advanced settings" to set a "query timeout". This was added in CF 9, but many never noticed. If that's your problem and you want to skip to more on that here, feel free. but you may want to come back and read the rest as it is STILL not a perfect solution.

Strap on your seatbelts. We're going for a bit of a ride (if this situation was easy to understood in the length of a tweet, then perhaps everyone would already understand it and not find it challenging!) As always, I welcome feedback.

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

How do I love FusionReactor? Let me count the ways (6 minute interview video)

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.
The folks behind FusionReactor have started a YouTube video channel and they recently posted a 6-minute interview with me that we did at CFUnited. In it, they ask and I recount the reasons I appreciate and recommend it. Check out the video, embedded also below.

FusionReactor is one of the leading CF Server Monitor tools, which works not only with CF 6/7/8/9, either Standard or Enterprise, but it also works with Railo, Open BlueDragon, and even BlueDragon JX 7.1. In fact, it works with any J2EE/JEE server or servlet engine.

If you're running a site on any of those platforms and ever have problems of slowness, instability, or any other "curious" problems, or just need to better understand the nature of requests that CF is processing, and how well (or poorly) it's doing it, FusionReactor is a great tool, for the reasons I outline. It's like having x-rays into the app server.

I've written and spoken about the tool quite a bit, and have a FusionReactor blog category here with over a dozen entries here, as well.

Coming review of "ColdFusion 9 Developer Tutorial" book by John Farrar, and a free chapter for you

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.
Today the publisher of John Farrar's new book, ColdFusion 9 Developer Tutorial offered to send me a review copy. I appreciate and look forward to that, as I've heard good things about it.

I'll post a review in coming weeks after I've had a chance to take a look.

Free Preview Chapter on ORM

In the meantime, they have also offered for free one of the chapters in the book so you can get a taste of the book's approach.

It's chapter 4, ORM Database Interaction, and as you'll see John leads you gently through this important new feature of CF9. Assuming you have no prior experience with ORM, he works in 20 pages from introducing the concepts, to quickly configuring and coding, to working with relationships, and more. You'll see he uses lots of screenshots and example code.

One editorial/review comment: I did notice that the preview chapter lists a last section to be on "custom configuration", which isn't ever found in the chapter. I brought this to John's attention and he apologized that it slipped through.

Having contributed to several books myself*, I know that can happen and I don't regard it as a big deal. It doesn't take away at all from the rest of the book.

Looking forward to the rest of the book

As for that rest of the book, and why you may want to consider it, the introduction indicates it "will teach you the basics of ColdFusion programming, basic application architecture, object reuse, and ORM concepts before showing you a range of topics including AJAX library integration, RESTful Web Services, Unit Testing, building custom tags, and his hybrid example of tags and objects COOP" ... "with real-world examples of the hows and whys, to get more done faster with ColdFusion 9" ...[and] "also covers the new features of ColdFusion Builder and additional version 9 updates".

I'm sure it will benefit many, and I'll look into all that when I get the review copy, and I'll be back to pass along my observations.

*I'm sure the publishers of my own books would think it appropriate at this point to mention those other books, which are also out recently and updated for CF9. They are the ColdFusion 9 Web Application Construction Kit, Volume 1 (Getting Started), Volume 2, Application Development, and Volume 3, Advanced Application Development.

More Entries

Copyright ©2019 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting