Skip to main content
A
Anonymous
March 25, 2011
Answered

CF 9.0.1 Solr does not respect Java VM Path

  • March 25, 2011
  • 2 replies
  • 2219 views

As part of securing some of our machines for DoD use we have to maintain up to date Java versions.  To do this we install the latest JDKs and use the Server Settings > Java and JVM > Java Virtual Machine Path to then tell CF to use it.  We've been doing this since CF4 with no issues and when we moved to CF6+ we continued the process but also after doing this we then remove the jre folder from the runtime folder from within CF itself. Well I just setup and installed my first CF9 + Win 2008 R2 server and after doing this the Solr service fails to start.  This then had me digging into its folder structure and it has its own jre folder within its folder structure as well.  However using Sysinternals Process Monitor I can see the Solr service is NOT using the jre folder from within it's own structure but is actually going up and "trying" to use the runtime\jre folder which I've removed so it causes the service to fail.  I can actually remove the solr\jre folder as long as the runtime\jre folder exists.

So there are several issues with this.

  • Solr has yet another Java installation within itself
  • Solr does not use its own Java even though there's a copy there
  • Solr does not respect the overall Java VM Path setting
    This topic has been closed for replies.
    Correct answer

    Adobe replied to my bug with the location of the solr configuration variable to point it at the external JVM.

    ColdFusion9\solr\solr.lax

    lax.nl.currentvm=JVM_PATH

    This seems to be working correctly so far now.

    2 replies

    A
    Anonymous
    Correct answer
    May 4, 2011

    Adobe replied to my bug with the location of the solr configuration variable to point it at the external JVM.

    ColdFusion9\solr\solr.lax

    lax.nl.currentvm=JVM_PATH

    This seems to be working correctly so far now.

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    July 15, 2014

    I'd like to add a followup to this thread from 3 years ago, in case anyone may find it in the future as I just did doing a search for something. Keith's last note had discussed how to modify the solr jvm configuration file (solr.lax in CF9) to point to a new JVM.

    He had said the line to modify was that for lax.nl.currentvm but instead it's than lax.nl.current.vm. I clarify this as much for those who may be searching for references to it, so they may find this discussion.

    Also, FWIW for future readers, in CF10+ the file is now instead called jetty.lax and is also located in a different directory: \[cf10]\cfusion\jetty, or [cf10]\[instancename]\jetty if you have created a new CF10 Enterprise instance.

    Hope that's helpful.

    /Charlie (troubleshooter, carehart. org)
    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    March 28, 2011

    Brentil, I would assert that if Solr is "trying" to use the runtime/jre to find classes then perhaps your last point is not correct: maybe instead it IS honoring the classpath, but it's other than what you're seeing. Rather than rely on what you see as the textarea field of the Java and JVM page (for the classpath), look instead in the settings summary page to see what it shows to be the classpath.

    As for your removing the CF JRE when you would add a new JDK, that's interesting. I'd not heard of people doing it. Of course, the fact you used ProcMon to prove that Solr looked there if its own JRE was removed may be how you proved that when you added a new JDK for CF, it too still looked in the old jre location. Did you prove that? I would be surprised, and it could suggest that people who added a new JDK may not have always been leveraging it alone. That would be a surprise. Let us know if you did prove that. Perhaps others would want to start removing it--though this Solr problem is certainly another challenge in considering that.

    Will look forward to seeing how all this turns out.

    /charlie

    /Charlie (troubleshooter, carehart. org)
    A
    Anonymous
    March 28, 2011

    When we first started using CF6 we tested and proved that altering the JVM location moved all of the core java calls to that installed JDK installation.  At that point we would remove the jre folder from within CF since it was older and violation of DoD security policies.  We've been running that way since CF6 with no issues at all to development and production level applications.  All of the CF specific code resides within its own DLLs and JAR files that exist outside of the jre folder.  This is how CF can run off of the JRUN & other enterprise java servers.

    So one would expect that then if Solr has specific versions of its own files within its own special jre folder it would look there.  However instead it's loading from the jre inside of the CF folders.  I actually took and removed the jre from inside of the Solr folder to test it and all it cared about was the existance of the one in the CF folder.

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    March 28, 2011

    Thanks for the clarification on why you would remove it in the past.

    As for the problem you're having with Solr, I'm just explaining that Java has a notion of a classpath, which is a list of directories through which the JVM will look when trying to load a class. If you look at what CF shows to be the classpath, then THAT is why it's looking where it is.

    Does that help?

    /charlie

    /Charlie (troubleshooter, carehart. org)
    Firefly Community Gallery
    Adobe Firefly

    Remix with Firefly Community Gallery

    Thousands of free creations to fall in love with and remix in Firefly.

    Explore now
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices