[Looking for Charlie's main web site?]

CF911: 'Help! I've updated the JVM which ColdFusion uses, and now it won't start!'

Has this happened to you?
  • You wanted to update the JVM which CF uses to use a new version
  • so you found some resource on the web showing how to update, and it seemed simple enough
  • and then you tried restarting CF and wham, it won't start
  • and now you're stuck wondering, "what happened? and how am I supposed to fix this?"

It's a tragic position to be in, of course.

There are several reasons why your attempt to update CF's JVM can fail.

And fortunately I can offer several things you can consider/look at, some of which may quickly recover from or be able to undo (depends on what you did). And all this applies to Lucee, Railo, and BlueDragon as well, though folder locations will differ.

In brief, here are the things you may have done wrong. See below for solutions or recommendations:

  1. You may have told the Java installer to install itself WITHIN the CF directory. You should not do that.
  2. You may have gotten the wrong kind of Java installer
  3. You may have gotten the wrong bit-level of Java for your bit-level of CF
  4. You may have gotten the wrong JVM for your OS
  5. You may have tried to use a JVM not supported by the version of CF you're running
  6. You may have pointed CF to the wrong JVM location
  7. You may have updated the JVM config for the cfusion instance, but not your other instances
  8. You may have forgotten to change the path's directory separator slashes on Windows
  9. You may have to copy the msvcr100.dll from the JVM's lib to CF's when updating older CF's to Java 7+
  10. You may have to copy the tools.jar from the JVM's lib to CF's when updating older CF's to Java 8+ (and delete some files compiled for the old JVM)
  11. You may find that Solr integration (and/or PDFG in CF11+) stops working, because you didn't realize you needed to edit *its* jvm config file

While I'm at it, I also cover:

  • Why you'll find that CF can't even STOP (let alone START) if you make a mistake with the JVM configuration
  • What JVM version(s) are supported by what versions of CF
  • Dealing with SSL Certificates you may have imported into a previous JVM
  • Beware leaving the Java installer to choose the "public jre" option

So this really became quite a compendium of resources on changing the JVM CF uses, but again the focus is on why CF may not start if you make certain very common mistakes.

First, if you're facing this bind right now, you can skip over the following and next section ("it all seemed so simple"), to the one which follows, "So what went wrong?".

As for why I'm writing this post, someone today made this very plea for help in a comment on the Adobe blog, and I started to write a reply there. It became too lengthy for a comment, so I am posting the answer here and pointing to it there. And as often happens, I have then elaborated still further, all just trying to help those looking for answers. (This is one of those topics where often often comes from the very fact that some explanations out on the web are just not complete enough.)

Some context: it all seemed so simple

So you had some reason to want to update the JVM in CF:

  • maybe you discover for the first time that the JVM which CF comes with is rather old (they had to pick one to include, when they first built that version of CF, and it isn't long--perhaps only days before or after a CF release--that an important new JVM update comes out)
  • Maybe you're finding that calls to https pages are failing from within cfhttp, cfinvoke, cfobject/createobject, and you heard that it's that the site you're calling has updated (or removed) levels of SSL/TLS supported, and that you should update your CF to a later JVM that support such later versions of SSL/TLS
  • Or perhaps you hear that CF can now support a new JVM, like how CF11 update 3 and CF10 update 14 each added support for Java 8, and you want to make that move.

So you may want to update CF to use a later jvm version, whether from one point release to another, or from one major release to another.

So you google around, find some instructions, and it seems simple enough. (And indeed, if done correctly, it's literally a 5 minute job which is easily reversed if needed.)

So you take a deep breath, and do the update as seems right from what you've read, and you restart CF, and...oh $#!+, it won't come up. (Or maybe it won't even go down. More on that in a moment.)

Now you panic, and you re-read the resource you read, only to find that it tells you only how to make CF use the new update. It doesn't tell you how to recover if things go wrong. And it probably didn't warn you of what to watch out for.

So you google around some more to try to find out what went wrong, and you find lots of people offering lots of suggestions, only they may or may not apply to the particular approach you used to make the update (and you may have made a grave mistake, like telling the Java installer to put itself INTO the CF JRE directory--a real no, no).

And now you curse that you ever started...

But your clients or bosses are breathing down your neck because CF has been down for 3 hours...

And you were just trying to do the right thing...

(And now's probably not a good time for me to comment about how it would have been wise, if doing such a JVM update for the first time, to try it on a local development environment, or a test machine, rather than a production machine. And of course to take a backup or vm snapshot.)

(Finally, if you're reading to this point and wonder "so I was wondering first just how do I update my JVM?", that's a different matter. I'll point out some resources at the end. While some do a good job of pointing out gotchas, I've not seen in one place anywhere all the following observations of problems and solutions. Correct me if I'm wrong. Anyway, I'm speaking in this entry to those who already did do it, either of a couple of ways, and are now finding that CF won't come up.)

So what went wrong?

So you updated CF to use a new JVM, and now CF won't start? What's the problem? Where did you make a mistake? Now, I don't know what particular approach you took (there are various possibilities), but there are several very common mistakes, and some are easy to recover from.

The good news is that I have here some clear suggestions, and in most cases your solution to this problem is only minutes away. I've been helping people either update their JVM, or helping recover from such mistakes, for years in my consulting practice.

So what might have gone wrong?

  • Challenge: First, let me address a pretty common mistake, and while it may not keep CF from running, it can in certain situations: when you ran the Java installer, and it asked where it should put itself, did you tell it to install itself into the java directory within CF, for instance, the C:\ColdFusion11\jre in Windows? You don't need to do that, and I'd argue you shouldn't. You may have problems, depending on some circumstances. And especially if you made any of the other mistakes below and may need to uninstall that JVM and install a new one, you will have obliterated the one built-into CF, if you may want to get back to using that one.

    Recommendation: Instead, you should typically install the new JVM outside of CF, and then point CF to that (either using the CF Admin or by editing the jvm.config), as I'll discuss more below. That way, if you wanted to get back to the original JVM, you can switch it back to pointing to that CF jre folder (like the C:\ColdFusion11\jre, in Windows.) I'm afraid if you've done this and are having problems, you may be best just reinstalling CF, or if you have a system backup (or VM snapshot), perhaps you can recover the CF directory to as it appeared before you started this effort.

  • Challenge: Second, let's note that there are 3 kinds of JVM downloads one can get from Oracle. They're not all the same, and not all will work with all implementations of CF. For instance, the next most common mistake is to download and install a Java "JRE" where you may really need a "JDK". The Oracle site (and google) may guide you to getting a JRE, but you want to instead look for a JDK. (Now, some will say they do get by ok with a JRE on anything but 32-bit Windows, or that the "Server JRE" will work though I've seen problems there, so I just recommend a JDK to be safe as a matter of course. It's never let me down).

    Recommendation: Here's some great news if you got a JRE and need a JDK: you can simply install a JDK even if you've first installed a JRE, no problem. They install to entirely different directories. Just do that install, and note the location of the JDK (technically, the JRE within the JK) and then change CF to point to that. (For more on how to tell CF to use a particular JVM location, and how to find it after installing Java, keep reading.)

  • Problem: continuing with other common mistakes, and moving on to those that can definitely keep CF from starting you may have gotten a JVM at the wrong bit-level for the version of CF you're running. If you're running a 64-bit version of CF, you need a 64-bit JVM. (And even if you're running on a 64-bit machine, if you're running a 32-bit version of CF, you need then a 32-bit JVM!). The download page uses some rather old nomenclature: the "i586" indication for Windows (as in jdk-7u71-windows-i586.exe file, for instance) means a 32-bit version of the JVM.

    Solution: Again just install the right one. They may each install into their own directory by default and can co-exist, though I've not tried that. It's probably best to uninstall the "wrong" JVM which you installed first.

  • Problem: you could have downloaded the wrong JVM for your OS. This is a little harder to do by mistake, but double-check what file you got against the list shown, such as that for JDK 7.

    Solution: Again, get the right one and try again.

  • Problem: you may be trying to use a JVM not supported by the version of CF you're running.

    Solution: Java 8 and 7 are only supported in certain CF version/update combinations. For more, see the discussion below, So what JVM is supported by what versions of CF?

    Assuming you didn't make this mistake, and you DID install the JVM into its own location, then you may have read how you're then to tell CF where that JVM is installed. But here's the next common mistake...

  • Problem:: You could have pointed CF to the wrong JVM location (whether you put that location path into the CF admin or the jvm.config).

    Solution: Point CF to the right JVM location. But there are some gotchas, which I discuss here and in the next "problem".

    For instance, if you are manually configuring the jvm.config file entry, you should point it not to the location of the JDK itself (like C:\Program Files\Java\jdk1.7.0_71) but to the JRE directory within that folder (and yes, a JDK has a JRE within it).

    So that on Windows, for instance, with a Java 7 JDK, you'd point to C:\Program Files\Java\jdk1.7.0_71\jre. (Well, technically if you're editing the jvm.config it would need to be specified as C:\\Program Files\\Java\jdk1.7.0_71\\jre. See 3 points down.) In Linux, the path may be something like /usr/java/j2sdk1.7.0_71/jre, for instance.

    (Interestingly, if you use the CF Admin "Java & JVM" page to enter the path in the "Java Virtual Machine Path", you can put the path in without the /jre and it not only accept it, but it uses it correctly. Under the covers, it changes the jvm.config to append the /jre for the java.home value. Curiously, though, while you'll see that reflected in the CF Admin pages "system information" and "settings summary", the "Java & JVM" page will still shows the path without the /jre (if you entered it that way here.)

  • Problem: if you put the new location to the JVM into the CF Admin (Java & JVM page), and made that any of the mistakes above (so that it points to an incorrect JVM), again you'll find that now CF won't start and so you can't access the CF Admin. What do you do then?

    Solution: Well, there's really good news here. Changes you make to that CF Admin page are simply put into their respective place within the jvm.config file CF uses. Specifically, it edits the java.home line (usually the first non-commented line in the file). You need to find that file, and correct the path to be the correct location.

    Where that file lives depends on the version of CF. In a server or Standard deployment of CF 9, for instance, it's in the [coldfusion9]\runtime\bin directory (wherever you installed CF). In CF10 and above, it's in [coldfusion10/11]\cfusion\bin.

    And if you run the Enterprise edition of CF and are using multiple instances of CF, that's worthy of its own discussion, netc.

  • Problem: if you are running CF Enterprise (or Trial or Developer edition) and are using multiple instances (what CF9 and before referred to as a "multiserver" deployment), note that you must change the jvm config affecting each instance that you want updated. Especially in CF10 and above, where each instance has its own jvm.config, it's not enough to just update the main "cfusion" instance.

    Solution: Let's take CF9 first: in a CF9 multiserver deployment, the jvm.config file in found the jrun4\bin directory. You'll find that CF9 multiserver instances don't offer a "java & jvm page" so you MUST edit the jvm.config file to change the jvm location. Now, by default, all instances in CF9 (and earlier) do share one jvm.config, so technically you could just change that one file and affect all instances. It is possible for someone to have configured separate jvm.configs for each instance, in which case you'll need to edit each. That's beyond the scope of this entry, but I discussed it here.)

    Moving on to CF10 and above, some great news is that each instance DOES have its own jvm.config, and you'll find it in the [coldfusion]\instancename\bin folder. BTW, in CF10 and above, you WILL find that each instance's CF Admin does ALSO have a "java & jvm" page, which is nice.

  • Problem: if you're on Windows, and made the change to the java.home location in the jvm.config (as described above), beware that you can't just drop the path in as it's reported by Windows. You need to change the directory separator slashes.

    Solution: So C:\Program Files\Java\jdk1.7.0_71\jre should be used instead as C:\\Program Files\\Java\jdk1.7.0_71\\jre or C:/Program Files/Java/jdk1.7.0_71/jre. This is just a "java thing", a vestige of its *nix heritage it would seem. (BTW, one advantage of using the "java & jvm" page of the CF admin is that it takes care of this correction to the slashes--but it comes at the cost that if you point to the wrong JVM location, as discussed two points above, then you can't use the Admin to correct that mistake, because CF won't start. You'll then need to edit the jvm.config, as discussed in the previous point.)

    And note that you do not want to leave a trailing \\ or / (depending on your choice above) or you may find that when you try to visit the CF admin "Java and JVM" page, you get an error, "Element JDKPATH is undefined in FORM". And you may find that it also causes errrors on other admin pages, of the sort "String index out of range: -1 null".

  • Problem: For those on CF9, if you apply the CHF which added support for Java 7 (such as CHF4 for 9.0.1), even if you do everything right, you may find that CF won't start. You may need to copy a needed file from the JDK to CF's directories.

    Solution: This is indeed discussed at the bottom of that technote (I just linked to), but in their rush to be done with the CHF people often miss it. I'll quote from from the page itself: "You can get the following error when starting a ColdFusion instance configured with JDK 1.7:

    "MSVCR100.dll is missing."
    To resolve this issue, copy msvcr100.dll from {JDK Home}\jre\bin to {ColdFusion-Home}\runtime\bin."

    You can see that Adobe mentioned this in the technote for the CF9 update that added support for Java 7. You can see still more in this blog post from Jochem Van Dieten the 2008 era.

    It's unclear if this problem would hit anyone updating to Java 7 after applying the updates for CF 10 and 11 which support Java 7 (see below).

  • Problem: Finally, for those CF10, if after applying CF10 update 14 you try updating it to run with Java 8, again even if you do it all correctly, you may find that web services (cfinvoke, cfobject, createobject) don't work.

    Solution: You may simply need to copy ANOTHER needed file from the JDK to CF's directories. This is covered in an Adobe CF team blog entry: "If you are using ColdFusion Web services you will have to do a one-time change manually. You should copy tools.jar manually from {JDK8_Home}/lib to {cf_install_home}/cfusion/lib/. ColdFusion Web Services will fail if this is not done."

    To be clear, a) if there is a tools.jar there already you will want to replace it with this newer one, and b) you do need to do that for each instance, not just /cfusion (that tip was written by Adobe presuming one had only the one cfusion instance.)

    Here's a fragment of at least one ind of error one may get if you don't do that update of the tools.jar: "cannot access java.lang.Object bad class file: java\lang\Object.class(java\lang:Object.class) class file has wrong version 52.0, should be 50.0".

    Finally, related to this, note that with the new JVM and tools.jar, you will find that you likely need to delete the old files compiled by CF for that old JVM. In particular, you'll want to delete the stubs folder under the cfusion folder (and for any other instances you may have). That removes previously compiled Java stubs for web service invocations you make. They will be recreated when the web services are next invoked. (It would be wise to stop CF, copy in the tools.jar, delete the stubs, and then restart CF.)

    Some may want to also delete the files in the wwwroot\WEB-INF\cfclasses folder (under cfusion and each instance you may have), as these hold the compiled version of all other CFM and CFC templates as they are first executed after any update. This will force CF to simply recompile them, again on their next execution, but using the new JVM. This is not always a necessary step but there have been times when certain JVM updates did warrant this.

  • Updated: Problem: Since posting this entry, I was reminded in the comments about another issue which can bite you when you update the JVM that CF uses. You may find that now certain things in CF don't work, specifically the integration of CF and Solr (though tags like CFSEARCH, CFINDEX, and CFCOLLECTION), or the new PDFG feature (in CF 11 above, using CFHTMLtoPDF). You need to edit the Solr (or technically, the "jetty") jvm config file.

    Solution: The issue is that the configuration of Solr (technically, Jetty, bundled within CF) by default points to the JVM that is built into CF. The solution is that you need to also change that config file (in windows, the jetty.lax file; in linux, the cfjetty file) to point to the same new JVM that you have pointed CF to. I discuss the details in the comment below.

Hope that lists helps someone. If you have other ideas, fire away.

I'd also like to have added here the various error messages from the logs that people get, to help them find this if they go a-searching for them. I've already spent way more time on this than I'd planned, so I'll add that later (and I welcome any comments from folks who already have those error messages in hand). Thanks.

Before we wrap up, there are a few miscellaneous related points I do want to make.

Beware: CF won't even STOP if you make those mistakes above

BTW, I mentioned earlier in the entry that if you make some of these mistakes, you'll find that CF won't even STOP let alone start. That's important to understand.

Many don't realize it but when you "stop CF" it kicks off a Java process which reads the same jvm.config file used to start CF, so if you make one of these mistakes and then try to restart CF, it won't stop let alone start.

In that case, you'd want to use your operating system to kill the cf process (coldfusion.exe or coldfusion in CF10+, jrun.exe or jrun in CF6-9). Then recover using the info above, and start CF again.

How to go about updating the JVM

So after all that, someone may say, "ok Charlie, but could you also tell us how to update the JVM?" Again, the focus here was "you already tried it, and it failed. How do you recover". As much as I'm tempted to outline here how to go about it, honestly there are several resources that already do it, with varying degrees of detail (and some showing different approaches), so I'd rather point to them here:

There are still others, and perhaps better ones with clear walkthroughs and gotchas. I welcome additions.

Again, it really should be quick and painless

I'll just say in summary that again changing the JVM which CF uses should really be just a 5-minute job.

In brief, you install the JDK (to a directory outside of CF), you change the jvm.config to point to the new JDK's JRE directory (saving a commented copy of the line pointing to the original one), save that file (don't close it), and restart CF. If anything goes wrong, go back to that file you just saved and see if you made one of the mistakes above.

And if you're still in a bind, do look to the CF logs to see if you find an explanation. (In CF9 or earlier, rather than the logs director though, when running CF as a Windows service, see the coldfusion9/runtime/logs or jrun4/logs.)

Finally, if you are really stuck, contact me for what may be just a quick consulting session. If I can't help, you won't pay for the time. I offer a satisfaction guarantee for my assistance.

So what JVM is supported by what versions of CF?

I mentioned above that one problem people get in trouble with is they try to update the JVM to a version that is not supported by their version of CF.

For instance, CF supports Java 8 only on CF10 and 11, and that only after certain updates in each case (updates 14 and 3, respectively).

And while CF supports Java 7 in CF11 by default, it only is supported for CF10 after applying update 8, and for CF9 only after applying a certain CHF (the CHF number depends on the point release of CF9 you're running). For more, see this Adobe blog entry.

Fortunately, the CF team has recently come out with a blog entry on this very subject. Do check that out. (Update in Oct 2016: they created yet another post which is a bit more updated.

Another gotcha: SSL certificates

Do beware also that if/when you change the JVM that CF uses, you cause one perhaps unexpected result: if you may have previously added certificates to the Java key store (such as to make SSL requests to certain URLs work from within CFHTTP), you will find that when you switch JVMs, you seem to lose these certs (and your CFHTTPs using those certain SSL-based URL requests start failing again).

Well, you haven't technically "lost them". The problem is that, assuming you started with CF using the JVM it came with, when you followed any of the many instructions on the web for using the keytool to add the cert to the keystore, you were doing that to the keystore WITHIN THE JVM THAT CAME WITH CF.

If you change to use a new JVM, then you may need to get those certs into the new JVM's keystore! (Note that I say you "may need to", because sometimes the cert you were installing was because the old JVM didn't include it, but perhaps you'd find the new one would and you need not add it. I'd propose you confirm if you need it first, whether by testing or by using the keytool option to list the certs and compare what's in the old and new keystores.)

Now, some people propose just copying they keystore from the old JVM to the new one, but that's unwise because the base keystore in the new JVM could have been updated by Oracle, and your copying over that would lose those base changes.

Fortunately some of the resources on the web, which show how to use the keytool to add a cert to the keystore, do go a step further and warn you that if you have changed the JVM CF uses, you need to be sure to update that JVM's keystore and they show how to do it. Again, this is not the place to detail that. Just pay attention to what any of the resources tell you, and be sure to point them to the keystore location WITHIN the JVM you are installing.

One last gotcha: Beware the Java installer's "public jre" option

One last point (this is a new one I've added since I first wrote this post in 2014): do beware that when you run the Java JDK installer, it will have a few options, one of which is the "public jre". You should generally choose NOT to install that, both for security reasons (not wanting the "java" command being executable from any directory on your server), AND also--most important to the above--to prevent Java from later prompting you or someone else to let it update itself, which then could break CF.

I started to add my reasoning here but decided to create a new blog post, Why you should think twice about leaving on the "public JRE" option of the Java JDK installer . See that for this additional important info.

You can get help if you need it

Phew, that's a LOT of stuff to consider about updating the JVM that CF uses. And yet so often when you see discussions of it, those never get into these details. Hope they have been helpful.

Again, if you need help with anything above (and want more than just to ask a question as a comment here), reach out to my via my consulting services, where I can help remotely and usually quite quickly as well as safely and easily (even if you "can't allow remote access"), and with satisfaction guaranteed.

But of course I do welcome questions and comments here. I do hope this is a useful blog entry and that you may even share it with others, as the subject is one that many trip over but few may find just by me posting it here.

Comments
Nice article Charlie. You covered, almost all possible scenarios.
# Posted By Anit Kumar Panda | 12/11/14 9:25 AM
Though a bit tangential, what about ODBC datasources in Java 8? I heard that the JDBC-ODBC bridge is no longer supported in Java 8, so will we lose access to legacy dsn's with a Java 8 upgrade?
# Posted By Andy K | 12/11/14 10:45 AM
Excellent write up Charlie! I've learned most of this through trial and error over the years and not much of it is "obvious" or "intuitive" to the typical CF dev. It's important to note that you won't get anything in most of your CF logs because without a JVM, the logging libraries can't even load! The "out" log may be the only one I've seen messages actually in for JVM load failures. Otherwise, you've got to start CF from the console which is also outside of most people's usual debugging toolset.

I think everyone should have to pay you just to read this article. Who says you're taking them for a ride when you put this much info out there for free? :)
# Posted By Brad Wood | 12/12/14 1:28 PM
Superb post as always Charile.

Just to add a further scenario I encountered the other day on my 64bit dev machine on which I use the 32-bit version of CF9 (due to installer issues).

I'd updated the 32-bit JDK and all was fine. Then I installed a 64-bit public JRE for another app, and again all seemed fine. The next time I restarted CF9 though, it failed.

I knew it was JDK related because my CF Solr service uses the same JDK as CF (good tip btw - do it in the solr.lax file) and that wouldn't start either. Uninstalling the new JRE and RE-installing the 32-bit JDK solved the issue. Some sort of corruption going I guess.
# Posted By Julian Halliwell | 12/13/14 4:06 AM
Julian, thanks for the kind regards and sorry that I missed this when you posted in December.

You do bring up a good point about JVM updates for CF and for other things, including Solr which runs inside CF. First, you mention the solr.lax file and that was indeed its name (in Windows) for CF9, but for CF10 and up, it's the jetty.lax file (in the [cf10]\cfusion\jetty folder (or instancename\jetty if using multiple instances).

Second, most will find that it has a line/argument (lax.nl.current.vm) which points to the JVM within CF (C:\\ColdFusion10\\jre\\bin\\javaw.exe, in the case of CF10 on Windows).

(In Linux, instead, you would edit the \opt\coldfusion10\cfusion\jetty\cfjetty file, and find the line, "SOLR_JVM="/opt/coldfusion10/jre", again as of CF10.)

Just as has been related in the blog entry above, about how if you change the JVM which CF uses you need to also consider related changes to the keystore, there is a similar connection between the JVM which CF uses and the one that Solr uses (assuming you're using the Solr installed with CF).

If (as it does by default) the Solr configuration points to the JVM *within* CF, then if you change CF to point to another JVM, then they (CF and Solr) will be out of sync with respect to JVM versions, which has caused some folks problems.

And then you are pointing out yet another problem: you refer to a "public JRE" that you installed. For those familiar, this is the terminology used by the Java installer as an option you can enable or disable at installation, and it's enabled by default, whereby the java command can run from anywhere on the machine (in any path) because the java.exe (in Windows) has been added to the path environment variable. That doesn't affect CF, since it points to the JVM it wants to use (in the jvm.config's java.home line). Even so, I tell folks not to implement the public JRE for the very reason you mentioned, where one thing depending on it didn't like the new version you installed.

As for Solr, though, as was just stated above it uses the JVM as indicated in the .lax file and lax.nl.current.vm line (for WIndows, or the cfjetty file's SOLR_JVM line in Linux).

So as for things breaking when you DID install a new JRE, I wonder: did you perhaps put it in the same location that CF (and Solr) were looking at? If you point the installer to a given dir, like \java\jdk_xyz, that wouldn't distinguish if it was a 64- or 32-bit jvm, and so if CF running as 32-bit had been pointing to that for a 32-bit jvm and you updated that location to have a 64-bit one, that could have explained your problems.

Hope that's helpful.

At least, though, I do hope that readers of this blog post will take to heart the realization that if you tweak the JVM for CF to point to some newly installed one in a new location (as recommended above), do beware that by default the Solr config within CF will point to the JVM that CF *came with*, and YOU need to change it to point to the new location, just like you told CF to do.

(And all this is because the Solr configuration within CF really runs its own JVM, its own process: jetty. BTW, this same Jetty process runs not only Solr but also in CF11 the new PDFG feature, for "pixel-perfect PDF generation" by way of the new CFHTMLtoPDF tag. If folks start hitting memory, heap, or other problems, this could be the root cause of those problems, too.)
# Posted By Charlie Arehart | 3/21/15 11:21 PM
Fantastic blog post, thanks! Solved all my problems - had been struggling to update my JVM for hours, but your note about the MSVCR100.dll solved everything! Thanks.
# Posted By James | 8/21/15 8:36 AM
Very good to hear. Thanks for the kind regards, James.
# Posted By charlie arehart | 8/21/15 9:26 AM
I have updated per your instructions and all works well. I am trying to follow the CF11 lockdown guide and when I check the J2EE session variables box located in the Memory Variables page, CF11 will not start. I am using Windows Server 2008R2 64-bit with ColdFusion 11 64-bit with Update 7 applied. Any suggestions would be appreciated.
# Posted By Susan Hurst | 12/10/15 7:18 AM
Fixed the issue after three days of searching. You need to uncomment out the following tag in runtime\conf\context.xml = <manager pathname=""/>
# Posted By Susan Hurst | 12/10/15 7:41 AM
@Susan, thanks for sharing your observation. I'm glad that you found your solution 23 mins after posting the problem here, though I am sorry if this was the 3rd day of searching.

I would have pointed out the same xml entry as a possible thing to consider, since you said the problem started when you enabled J2EE sessions.

As for why it was commented in the first place, I would suspect it means that you had a CF11 installer which had been released in early Dec 2014 and obtained before mid-Jan 2015 when they created a new one that fixed the issue. This was blogged then:

http://blogs.coldfus...

It also mentioned the option of just changing that xml line yourself. There were other blog posts on it at the time:

http://christierney....

It also led to another problem, about securerandom, outlined here:

https://coldfusionso...

which also pointed to either changing that XML or getting the updated installer.

Of course, I realize that before you found the solution, you may not have thought to use words to search that would have led to these. I'm pointing this out as much for others who may see this.

But also, finally, you may want to go get an updated CF11 installer, so that you don't cause the problem again if you ever need to reinstall, or use it to install on another server.

Does this seem on the right track?

For instance, do you know when you downloaded the installer? If it was more recently, that would beg a new question of why that xml setting was commented out for you.

I'll add that you or someone there could have done it, in considering the idea of using session persistence in Tomcat. That's what commenting it does. And if it had been changed in the past, perhaps as part of some testing, it would not have taken effect until you DID turn on J2EE sessions.

And that's what caused your problem when you restarted, if it found many sessions to be persisted (perhaps thousands or more). And those may have been persisted either when you shut down (after changing to use J2EE sessions), or the persisted sessions may have been left over from when that was last done (commenting that out and having J2EE sessions on) some very long time ago.

Let me know if this is helpful.
# Posted By Charlie Arehart | 12/10/15 3:42 PM
Charlie - thank you for getting back to me so quickly. I checked my download that I was using and it is from December 2014. I have gotten a new download from Adobe Website so hopefully I will not have this issue in the future. The websites you provided were also very helpful and informative. Again, that you.
# Posted By Susan Hurst | 12/11/15 11:22 AM
Ghaaa - this helped completely for addressing the "you need TLS 1.2" - easy update following your approach to explaining installing updated Java. Knowing you had outlined all the exits from it going bad, I had full confidence running the update.

Thank you!
# Posted By Stephen Cassady | 8/25/16 2:45 AM
In the style of Charlie Arehart, here is a SHORT ANSWER I want to warn any Mac users out there about (the long answer will come when I get some more time).

If you are on a Mac, CF9 is HARD-CODED to use the last "Apple-Blessed" version of Java, which is Java 1.6. You can install 1.7 or later, and even follow these instructions to point the CF JVM to the new version in the Admin. But if Apple-supplied 1.6 is not there, you will get a "missing software" error on CF start-up.

More details can be posted if anyone wants them.
# Posted By Troy Allen | 8/15/17 11:50 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.005. (Want to validate the html in this page?)

Carehart Logo

Managed Hosting Services provided by
Managed Dedicated Hosting