The logging is coming from application which is running in Tomcat. Solr itself
is running in the embedded Jetty.
And yes, another look at the log4j and I see that rootlogger is set to DEBUG.
I've changed that/
>On the Solr server side, the 6.4.x versions have a bug that causes extremely
>high CPU usage and very slow operation. This will be fixed in 6.4.2, which
>>will hopefully be out soon. There is currently no ETA for this release.
Thanks for that. I will watch for the release.
>Another side issue: Using the extracting handler for handling rich documents
>is discouraged. Tika (which is what is used by the extracting
>handler) is pretty amazing software, but it has a habit of crashing or
>consuming all the heap memory when it encounters a document that it doesn't
>>know how to properly handle. It is best to run Tika in your external program
>and send its output to Solr, so that if there's a problem, it won't affect
>>your search capability.
That was frankly what I thought I was doing.
The calling code is:
public Long SolrIndex(String path, String target, String URL,
List<Role>roles, CurrentState curState) {
HttpSolrClient solr = new HttpSolrClient(URL);
try {
solr.deleteByQuery("*:*");
solr.commit();
} catch (SolrServerException | IOException ex) {
Logger.getLogger(JsMapService.class.getName()).log(Level.SEVERE,
null, ex);
}
... lot of stuff to find data to index and set fields
...
if (solrIndexFile(solr,filename,access,mi.getMcontent())) count++;
try {
solr.commit();
} catch (SolrServerException | IOException ex) {
Logger.getLogger(JsMapService.class.getName()).log(Level.SEVERE,
null, ex);
}
Notice: This email and any attachments are confidential and may not be used,
published or redistributed without the prior written consent of the Institute
of Geological and Nuclear Sciences Limited (GNS Science). If received in error
please destroy and immediately notify GNS Science. Do not copy or disclose the
contents.
