Hello Thank you for your answer. We have solved our problem now. I describe it for someone who could encounter a similar problem.
Some of our fields are dynamic, and the name of one of these fields was not correct : it was sent to Solr as a java object, eg solrInputDocument.addField(myObject, stringValue); A string representation of this object was displayed in the Solr admin page, and that alerted us. We have replaced this wrong field name by the string we expect and no more OOME occur. At least we could test diverse solr configurations. Regards Joel Gaspard -----Message d'origine----- De : Erick Erickson [mailto:erickerick...@gmail.com] Envoyé : jeudi 31 janvier 2013 14:00 À : solr-user@lucene.apache.org Objet : Re: Indexing problems I'm really surprised you're hitting OOM errors, I suspect you have something else pathological in your system. So, I'd start checking things like - how many concurrent warming searchers you allow - How big your indexing RAM is set to (we find very little gain over 128M BTW). - Other load on your Solr server. Are you, for instance, searching on it too? - what your autocommit characterstics are (think about autocommitting fairly often with openSearcher=false). - have you defined huge caches? - ..... How big are these documents anyway? With 12G of ram, they'd have to be absolutely _huge_ to matter much. Multiple collections should work fine in ZK. I really think you have some innocent-looking configuration setting thats bollixing you up, this is not expected behavior. If at all possible, I'd also go with 4.1. I don't really think it's relevant to your situation, but there have been a lot of improvements in the code.... Best Erick
