[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, or the admin won't open, or code starts failing
  • and maybe it's that things didn't fail immediately, but within hours or days folks report things breaking since you made the change
  • and now you're stuck wondering, "what happened? and how am I supposed to fix this?"

It's a tough position to be in, and tragic of course if CF won't start. But no, you do NOT need to reinstall CF!

Often it's just one thing you did by mistake, though there are indeed several possible reasons why your attempt to update CF's JVM can fail or lead to unexpected problems. And as you google about, you may find all kinds of helpful but often misinformed or spartan suggestions that may or may not help much.

So I offer here over a dozen of things you can and should consider/look at, some of which you 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.

If you're facing this bind right now, you can skip over the following to the the section, "So what went wrong?", where I present each likely problem and solution.

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

  1. You may have gotten the wrong bit-level of Java for your bit-level of CF
  2. You may have gotten the wrong JVM for your OS
  3. You may have tried to use a JVM not supported by the version of CF you're running
  4. You may have gotten the wrong kind of Java installer

    And while those above have to do with getting the RIGHT JVM, sometimes the issues arise with how you setup to point to that JVM:

  5. You may have pointed CF to the wrong JVM location
  6. You may have forgotten to change the path's directory separator slashes on Windows
  7. You may have made one of these mistakes, and now CF won't start, so you can't see the CF Admin to correct your mistake
  8. You may have updated the JVM config for the cfusion instance, but not your other instances
  9. You may have told the Java installer to install itself WITHIN the CF directory, though you should not do that

    Still other issues involves steps you must take AFTER updating the JVM, even if you do the change and point to the JVM "correctly" otherwise, especially when implementing a new major JVM version (like 6 to 7 or 7 to 8):

  10. You may need to copy a needed MSVCR100.dll file from one of the JVM's folders into one of CF's
  11. You may need to copy the tools.jar from the JVM's lib to CF's when updating older CF
  12. You may need to delete the java "stubs" that CF had compiled for web service calls using the old JVM
  13. You may need to delete the cfclasses folder, with the files created by CF when it compiled and saved such class files
  14. You may need to import SSL certificates into the new JVM--but beware, perhaps you don't NEED to!
  15. You may need to edit the Solr (or technically, the "jetty") jvm config file, so that it also points to the new JVM

While I'm at it, I also cover:

  • Beware that CF also can't even STOP (let alone START) if you make some mistakes with the JVM configuration
  • What JVM version(s) are supported by what versions of CF
  • 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.

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 beyond what I was going to write in the comment (and still more since first posting the entry here), all just trying to help those looking for answers. (This is one of those topics where most explanations on the web are just not complete enough to avoid falling into trouble.)

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.

And 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, in the section, "How to go about updating the JVM". While some of them do a good job of pointing out gotchas, I've not seen in one place anywhere all the following observations of problems and solutions. Anyway, I'm speaking in this entry mainly to those who already did do the upgrade, and are now finding that CF won't come up or work right.)

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?

  • Problem: 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 each install into their own directory by default and can co-exist. You could uninstall the "wrong" JVM, if you installed it and know that you don't otherwise need it for any other apps on the machine.

  • Problem: You may 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 that's where you can make another common mistake. Before that, let me make one more last observation of a possible mistake in WHICH JVM you get.

  • Problem: You may have gotten the wrong kind of Java installer

    This is not as common a problem as before, when many were running CF on 32-bit Windows.

    First, let's note that there are 3 kinds of JVM downloads one can get from Oracle: the JRE (Java Runtime Environment), the JDK (Java Development Kit, which includes the JRE), and the Server JRE (a trimmed down JRE, without an installer, means for some server deployments of Java).

    They're not all the same, but more important not all will work with all implementations of CF. For instance, you may 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 I (and others) will propose that you generally want to instead get 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 with that, so I just recommend a JDK to be safe as a matter of course. It's never let me down).

    Solution: Here's some good 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, as discussed next.

The next set of problems and solutions have more to do with how you go about telling CF to USE the new JVM once you have installed it (and whether you may have made one of the mistakes above first, and then found CF not starting after that.)

  • Problem: You may 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 installing a JDK, 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 the related point below.) 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: You may have forgotten to change the path's directory separator slashes, on Windows

    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, to either of two options.

    So where the actual windows path may be C:\Program Files\Java\jdk1.7.0_71\jre, you should change that to C:\\Program Files\\Java\jdk1.7.0_71\\jre (two slashes) or you can use the other slash: 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: You may have made one of these mistakes, and now CF won't start, so you can't see the CF Admin to correct your mistake

    So perhaps you installed the JVM and pointed CF to the new JVM location using the CF Admin "Java & JVM" page, but having made any of the mistakes above (so that it points to an incorrect JVM), you 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 CF10 and above, it's in [coldfusion10/11/2016]\cfusion\bin.

    In CF9 and earlier, with a server or Standard deployment, it's in the [coldfusion9]\runtime\bin directory (wherever you installed CF).

    And if you are using multiple instances of CF, then that's worthy of its own discussion (including where to find the files). See the next point.

  • Problem: You may have updated the JVM config for the cfusion instance, but not your other instances

    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 talk to those using CF10 and above, first. As you may know, each instance has its own jvm.config, and you'll find it in the [coldfusion]\instancename\bin folder. So just be sure to make the needed JVM config changes for each instance.

    In CF9, things were more challenging if you had multiple instances (supported by the Enterprise edition and its multiserver deployment option). First, there was ONLY ONE jvm.config, by default, and all instances shared it. Also, only the cfusion instance's CF Admin had a "java & jvm" page (in CF10 and above, each instance DOES have its own "java & jvm" page, also).

    So by default, in CF9 and below, there was just the one jvm.config file, and it was found the jrun4\bin directory. And if you were to edit that one file it would affect all instances.

    Note that 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.)

  • Challenge: You may have told the Java installer to install itself WITHIN the CF directory. I will argue that you should not do that.

    Recommendation: When you run the Java installer, it may ask (or you may tell it) where it should install itself, and you may be tempted to tell it to install itself into the java directory within CF, for instance, the C:\ColdFusion2016\jre in Windows? You not only don't NEED to do that, but I would argue you shouldn't.

    Indeed, this one may be a bit debatable by some. So notice it's listed here as a "challenge" with a "recommendation", rather than a "problem" with a solution. It's something I see many do, either based on someone's recommendation or just because they think it makes sense. While it may not keep CF from running, it can in certain situations.

    But bottom line, you MAY have problems (any of these here), and you may want or need to revert back to the old one, but now it's gone! And you can try to uninstall the "wrong" JVM (if that's what you did) and install a new one, but even that will still leave you unable to go back to the original, if you have told the JVM installer to put itself into the CF jre directory (not to mention it's also easy to get wrong exactly WHAT JVM to get--JRE or JDK--and then WHAT folder under CF to "put that in").

    Instead, you really should just 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 have discussed above. That way, if you wanted to get back to the original JVM, you can just swap comments in the jvm/config and switch back to it pointing to the original CF jre folder (like the C:\ColdFusion2016\jre.)

    If at this point you DID already make this mistake and are having problems recovering from it (perhaps even having messed up CF's JRE folder badly), 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.

And what follows now are more issues that may arise AFTER you have made the update (perhaps avoiding all the mistakes above), but where you find that while CF comes up and some pages work, some other pages (perhaps the CF Admin, or certain pages of yours doing certain operations) may fail. The first two apply more to older CF and JVM versions, but the next two may apply to later versions also, as explained there.

  • Additional step that may be needed: For those on CF9, if you update from Java 6 to 7, you may find that CF won't start. If so, you may need to copy a needed MSVCR100.dll file from one of the JVM's folders into one of CF's.

    So as discussed elsewhere, the ability to move from one major JVM to another is something that Adobe would need to formally support before you "just do it". And in the case of CF9.0.1, for instance, they offered support to move to Java 7 after you applied its CHF 4.

    Well, as discussed in the technote for CF9.0.1 CHF4, they note that: "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."

    So there you have it. (And while you should NOT update CF9 to use Java 7 until getting CHF 4 in place, I'll just say that if you do, this problem would apply to you as well.)

    You can see still more in this blog post from Jochem Van Dieten the 2008 era.

    (It's unclear if this specific problem and solution would apply to anyone on CF10--which came originally also on Java 6--who updates to Java 7 after applying the CF10 update which supports that.)

  • Additional step that may be needed: You may need to copy a needed tools.jar file from one of the JVM's folders into one of CF's.

    Especially after updating the JVM from one major version to another (like Java 6 to 7 or 8, or Java 7 to 8), you may find that web services (cfinvoke, cfobject, createobject) don't work.

    This is similar to the last issue, of course, and is covered in an Adobe CF team blog entry, where they wrote: "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."

    Yes, the refer there to Java 8, but again this may happen if you are going from any major Java version to another (6 to 8, 7 to 8), and it may happen with minor JVM updates, though I've not heard of it. (And it may well be needed when in the future CF supports a Java version beyond 8.)

    To simplify things, if there is a tools.jar in CF's cfusion/lib folder already, you will want to replace it with a newer one if found in the new JVM's lib folder. (If you "save off" the old one in the same directory, do NOT just call it tools_old.jar, as Java will still find and load any .jar file in a directory it looks in, so if anything, rename the old one tools.jar.old.)

    Also, note that you do need to do that for each instance you may have, not just /cfusion (that tip was written by Adobe presuming one had only the one cfusion instance.) And of course, you do need to restart CF once you put this new file in place.

    But you're not done. See the next step...

  • Additional step that may be needed: You may need to delete the Java "stubs" created by CF in the past when calling web services.

    This is related to the issue just mentioned above, about updating the major java version and the impact if your code calls web services (via cfinvoke, cfobject, createobject).

    Adobe recommends (in that blog post mentioned there) that you "also make sure that the earlier stubs are cleared fom (sic){cf_install_home}/cfusion/stubs/ to get the newly compiled classes."

    This is actually something that applies often when moving from one major Java version to another (even if the need to update the tools.jar may not apply somehow).

    What they mean is that if your CFML code had called web services, then CF would have created (compiled) Java stubs for those web service invocations. And they will have been compiled for the old JVM and so should be deleted as they may be incompatible with the new JVM. The good news is that the stubs will be recreated when any web services are next invoked. (It would be wise to stop CF, delete the stubs, and then restart CF.)

    Here's a fragment of at least one kind of error one may get if you don't do that update of the tools.jar (in case showing this here may find others find this post in the future): "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".

  • Additional step that may be needed: You may find that you will need to delete the files that were created by CF when it compiled and saved such class files, to avoid strange java errors.

    This is again similar to the last issue, about issues that can happen after updating the JVM from one major version to another (like Java 6 to 7 or 8, or Java 7 to 8), but this can apply to ANY kind of CF code. Here's the issue.

    When we use the "save class files" option in the CF Admin (which is on by default, and recommended for production), CF will compile and save (to the wwwroot\WEB-INF\cfclasses folder) a class file for each cfm and cfc file, and one also for each function or method in them. The issue is that when those were compiled and saved with the older JVM version, something about that Java code (in teh class files) may be incompatible with the new JVM.

    So some will find that they may want to just stop CF and delete all the files in their wwwroot\WEB-INF\cfclasses folder (found under cfusion and each instance you may have). You don't even need to recreate the folder, as CF will do it. (But be careful not to delete the similarly named "classes" folder in that same directory.) Then restart CF.

    This will force CF to simply recompile templates as they are executed, using the new JVM. (There should be little observable impact of this one-time action.) And to be clear, this deletion of the cfclasses folder is not always a necessary step, but there have been times when certain JVM updates did warrant this.

    Finally, related to this and as was discussed in the last point, you'll likely also want to delete the stubs folder under the cfusion folder (and for any other instances you may have). See the previous point for more on this matter (including how the stubs will be recreated if and when any web services are called from within CF), and don't forget to restart the instance/s!

  • Additional step that may be needed: You may need to import SSL certificates into the new JVM--but beware, perhaps you don't NEED to!

    You may find that when you switch JVMs, your CF pages using CFHTTP and similar tags/functions to call https URL requests may start failing. It may seem like CF has "lost" the certificates.

    Instead, it's that when you change the JVM that CF uses, you are also implicitly causing CF to use that new JVM's java key store (where certificates are stored), which is used by the Java code underlying CF which is called when you make https requests from within CFML with CFHTTP and the like.

    And any certs you may have put in before would now NOT be available to the new JVM (and to CF), unless you put them into that new keystore.

    But before you just go grabbing all those certs to import again, beware that you may not really NEED them. Sometimes, the reason you had to add certs to the CF/Java keystore was that the JVM was indeed old, and the certs there may no longer have worked--and so you were told to get new ones. But in moving to the new JVM, perhaps that problem is alleviated.

    I'd propose you confirm if you need any of the old certs at all first, whether by testing or by using the jvm keytool option to list the certs and compare what's in the old and new keystores.

    Further discussion of that (listing certs), let alone importing them, is beyond the scope of this blog post. But I will warn you to be careful to note that many instructions on the web for using the keytool (to add cert to the keystore) presume that you are doing that import into the keystore WITHIN THE JVM THAT CAME WITH CF. If you have changed the JVM, as discussed here, then clearly that is NOT where you want to import them (if you need them at all).

    Fortunately some such resources do go that important 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. So just pay close attention.

    Fnally, DO NOT just copy the keystore (cacerts file) from the OLD JVM to the NEW one! That's quite unwise because the base keystore in the new JVM could have been significantly updated (for the better), and your copying over that would lose those improved base changes.

  • Additional step that may be needed: You may need to edit the Solr (or technically, the "jetty") jvm config file, so that it also points to the new JVM.

    You may find that after updating the JVM, certain things in CF don't work related to the integration of CF and either Solr (though tags like CFSEARCH, CFINDEX, and CFCOLLECTION) or the new PDFG feature (in CF 11 above, using CFHTMLtoPDF).

    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.

So phew, that's a fair bit, but forewarned is forearmed. Hope that lists helps someone. If you have other ideas, fire away.

I've added here some of the various error messages people get in these scenarios, to help folks find this post if they go searching for them later. I welcome hearing from folks who may already have more such error messages on hand for me to add.

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

Beware: You may find also that CF won't even STOP, if you make some of those mistakes above

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, when editing the JVM configuration.

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 those mistakes above related to configuring CF to use the new JVM, and then you try to restart CF, you may find 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 set things right using the info above, and then try starting 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:

The

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
One more heads up for mac users... you might need to:
SUDO ./coldfusion start
# Posted By Jonathan Hayes | 2/1/18 2:25 PM
Thanks, Troy and Jonathan, for the additional notes for Mac users.
# Posted By Charlie Arehart | 2/5/18 1:29 PM
Copyright ©2018 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