Solr and Java Runtime Environment (JRE) Auto Updates

With Solr becoming more and more integral to Sitecore, I wanted to share one tip for taking Solr to production. I have been burned quite a few times by automatic updates made to the Java Runtime Environment (JRE) which is used to run Solr.

If you are running a production instance of Solr on a Windows box then you should double check that auto updates are disabled for the JRE.

It feels strange recommending against auto updates, but it is necessary in this scenario. The alternative is that your JRE version might auto update which will break your Solr installation. The issue will occur because your Solr installation is either looking directly at the JRE folder (which is deleted in favor of the updated version) or looking at an environment variable which will not be updated after the JRE updates are performed.

This is not something that is unique to Sitecore but it is something that can be easily overlooked in your Sitecore production environments. One more thing to add to your "go-live" checklist!


"Hey, I don't need to worry about this since I'm using a Solr installation stack like Bitnami that auto includes an installation of JRE." Wrong! You likely need a standalone JRE x64 installation if you want greater than 4GB of memory allocated to your Solr instance (which you do want!).

I highly recommend reading the following guide named "Taking Solr to Production":

For example, here is one important excerpt:

By default, the bin/solr script sets the maximum Java heap size to 512M (-Xmx512m), which is fine for getting started with Solr. For production, you’ll want to increase the maximum heap size based on the memory requirements of your search application; values between 10 and 20 gigabytes are not uncommon for production servers.