Had an issue this week where all SOLR collections on one of our ColdFusion 9 servers stopped working, and SOLR was not accessible from the CFADMIN either, with none of the collections showing.
Trying to add a new collection in the CFADMIN would result in this error
An error occurred while creating the collection: org.apache.solr.common.SolrException. Check the Solr logs for more detail.
The websites would be giving the error
The collection COLLECTION_NAME does not exist
Having never used SOLR, this took a fair bit of digging to resolve, Google turned up plenty of other people having this error but no solutions.
It turns out that whenever a SOLR collection is created, a set of configuration files are also copied into the location of the collection.
E.G.
You create your collection at
D:\wwwroot\mydomain.com\wwwroot\SOLR\collections\mycollection
Inside this folder will created a "conf" folder which contains a bunch of config files which SOLR needs to read in order to initialise and use your collection. these are copied from C:\ColdFusion9\solr\multicore\core0 on a default installation.
The first file it looks for is solrconfig.xml, if it cannot find this file then it will throw a configuration error and the default behaviour of SOLR is to simply abort when this happens, thus SOLR completely stops working.
To find out which collection is causing the abort you can check the SOLR admin, which by default is on http://127.0.0.1:8983/solr/ (thanks Jeff).
This will give you an error showing you which collection is causing your problem, the error should look like this
java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or 'D:\wwwroot\mydomain.com\wwwroot\search\collections\mycollection\conf/', cwd=C:\ColdFusion9\solr
There are 2 ways to fix this.
- Restore the missing files to the above folder from your backups.
- Remove the collection form SOLR
open C:\ColdFusion9\solr\multicore\solr.xml
And remove the offending collection.
Restart the SOLR service.
Now you should also notice on the SOLR admin error that it says:-
If you want solr to continue after configuration errors, change:
<abortOnConfigurationError>false</abortOnConfigurationError>
in solr.xml
This is actually untrue, I tried this and could not get it to work, so went and posted on the SOLR forums only to discover that this feature was actually removed long ago, even more odd is that it was voted to be removed by most of the community. Why they would vote to remove a feature that would stop SOLR from crashing and make it more stable is beyond me.
So what this means is that SOLR is completely unsuitable for shared hosting, where other users are going to cause this problem all the time, if someone deleted their collection, deleted their website due to rebuild or moving hosts, any action that removes the collection files is going to break SOLR.
The only safe way to remove a collection is with <cfcollection action="delete">
Jan 17, 2013 at 11:02 AM Very nice!
Thank you for this, as our production server has had this problem a number of times.
Dec 29, 2013 at 9:16 PM I miss the good ol' days of Verity search collections. I can't for the life of me figure out why Adobe switched to SOLR over Verity.
Verity definitely had it's problems but it was so much easier to administer.
Dec 29, 2013 at 9:30 PM Licensing costs I believe was the reason. SOLR doesn't cost them anything, verity did.
Mar 9, 2014 at 9:48 PM Verity ceased to exist as a product. That was the chief reason Adobe had to stop selling it.
--
Adam
Mar 25, 2014 at 12:25 PM whatever the reason, solr in its current state is not a viable replacement simply due to the issues raise din this article. It should at the very least be configured so that this cannot happen.