The logs stdout and stderr are blank. The log request had info, but nothing that is related.
Persistent flag is set to true in all environments. After backing up the solr.xml file, the collections were manually erased from the file allowing me to list collections without breaking! Yay. This allowed my script to create at least one of the collections. I'm sure we'll get the other, soon. Thank you to everyone for your help! Jack _______________________________________________ -----Original Message----- From: jack.drysdale....@ustranscom.mil [mailto:jack.drysdale....@ustranscom.mil] Sent: Monday, April 29, 2013 12:27 PM To: solr-user@lucene.apache.org Subject: RE: Bizarre Solr issue Hello, Shawn, and thanks for your reply. I will look into this, ASAP. I know that on one of the dev environments the persistent flag is set to "true"; I'll check the others and the production. I will also see if someone can get me a copy of the logs from the production environment to see if any more detail is contained within. Thanks, Jack -----Original Message----- From: Shawn Heisey [mailto:s...@elyograg.org] Sent: Monday, April 29, 2013 12:19 PM To: solr-user@lucene.apache.org Subject: Re: Bizarre Solr issue On 4/29/2013 8:15 AM, jack.drysdale....@ustranscom.mil wrote: > Production environment is *nix running CF 9.0.0, with both Verity and > Solr collections. > > Trying to list collections is breaking - one collection in particular > is breaking the CFCOLLECTION action="list": Error message states that > the solrconfig.xml file cannot be found. > > I unregistered this collection via CFAdmin, then went into the file > system and deleted the folders for this collection and restarted both > Application and Solr services. Ran the script, again, and still > getting the same error message for the collection that we just > completely removed. It's NOT being cached in the browser. > > This is working fine in development (Windows environment, CF9.0.1). CFCOLLECTION and CFAdmin are not part of Solr. We have no way of knowing what happens when you do things in CFAdmin. I do have one possible idea of what might be going wrong here, though. Here's how multi-core Solr works in all versions prior to 4.3: The directory named with the solr.solr.home property (defaulting to ./solr) contains a file called solr.xml. This file describes the index cores that Solr knows about and defines a few global settings. Solr includes something called the CoreAdmin API for manipulating cores and solr.xml, which is probably utilized by CFAdmin. If the solr.xml file is missing an attribute called persistent on the <solr> tag, or that attribute is set to false, then changes made using the CoreAdmin API are not persisted in the solr.xml file on disk, so when Solr restarts, it will use what it had before. Note: SolrCloud (4.0 and later) does add the concept of collections - a cluster-wide view of multiple cores. SolrCloud is not required, and with version 1.4.1, you won't have to worry about it. Thanks, Shawn
smime.p7s
Description: S/MIME cryptographic signature
