: : I don't know whether this is the good place to ask it, or there is a special : tool for issue : requests.
We use Jira for bug reports and feature reuqests, but it's always a good idea to start with a solr-user email before filing a new bug/request to help discuss the behavior you are seeing. : 2010.03.23. 13:27:23 org.apache.solr.common.SolrException log : SEVERE: java.lang.NumberFormatException: For input string: "1595-1600" : at : java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) : at java.lang.Integer.parseInt(Integer.java:456) : : It would be great help in some cases, if I could know which field contained : this data in wrong format. you are 100% correct ... can you let us know what the rest of hte stack trace is (beyond that last line you posted) so we can figure out exactly where the bug is? : "SimplePostTool: FATAL: Solr returned an error: For_input_string_15951600 : __javalangNumberFormatException_For_input_string_15951600 : ___at_javalangNumberFormatExceptionforInputStringNumberFormat...." : : (I added some line breaks for the shake of readability.) : : Could not be returned a string with the same format as in Solr log? Solr relies on the servlet container to format the error and return it to the user, with Jetty, the error does actually come back in human readable form as part of the response body -- what the SimplePostToll is printing out there is actually the one line HTTP "response message" which jetty (in it's infinite wisdom) set's using the entire response with the whitespace and newlinees escaped. If you us something like "curl -D -" to hit a Solr URL, you'll see what i mean about the response message vs the response body, and if you use a differnet servlet container (like tomcat) you'll see wha i mean baout the servlet container having control over what the error messages look like. -Hoss
