Have you checked the luceneMatchVersion in all your solrconfig.xml files? I'm guessing it't set to 40 somewhere in the process as evidenced by the line: org.apache.lucene.codecs.lucene40.Lucene40FieldInfosFormat.<init>( Lucene40FieldInfosFormat.java:99) so it looks like somehow a Lucene 4.0 codec is being used to try to read a more recent format.
You have three different Solr's you're trying to mix-and-match, so getting them all coordinated is "interesting". I'm guessing that when you instantiate the embedded Solr, you're pointing it at a pre-existing index, but that's only guessing.. Best Erick On Sun, Aug 11, 2013 at 2:05 PM, Dmitriy Shvadskiy <dshvads...@gmail.com>wrote: > Erick, > > Thank you for the reply. Cloudera image includes Solr 4.3. I'm not sure > what > version Amazon EMR includes. We are not directly referencing or using their > version of Solr but instead build our jar against Solr 4.4 and include all > dependencies in our jar file. Also error occurs not while reading existing > index but simply creating an instance of EmbeddedSolrServer. I think there > is a conflict between jars that EMR process loads and that our map/reduce > job requires but I can't figure out what it is. > > Dmitriy > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Problem-running-Solr-indexing-in-Amazon-EMR-tp4083636p4083855.html > Sent from the Solr - User mailing list archive at Nabble.com. >
