On Mar 27, 2012, at 10:51 AM, Shawn Heisey wrote: > On 3/26/2012 6:43 PM, Mark Miller wrote: >> It doesn't get thrown because that logic needs to continue - you don't >> necessarily want one bad document to stop all the following documents from >> being added. So the exception is sent to that method with the idea that you >> can override and do what you would like. I've written sample code around >> stopping and throwing an exception, but I guess its not totally trivial. >> Other ideas for reporting errors have been thrown around in the past, but no >> work on it has gotten any traction. > > It looks like StreamingUpdateSolrServer is not meant for situations where > strict error checking is required. I think the documentation should reflect > that. Would you be opposed to a javadoc update at the class level (plus a > wiki addition) like the following? "Because document inserts are handled as > background tasks, exceptions and errors that occur during those operations > will not be available to the calling program, but they will be logged. For > example, if the Solr server is down, your program must determine this on its > own. If you need strict error handling, use CommonsHttpSolrServer." If my > wording is bad, feel free to make suggestions. > > If I'm wrong and you do have an example of an error handling override that > would do what I need, I would love to see it. From what I can tell, add > requests are pushed down and handled by Runner threads, completely > disconnected from the request. The response to add calls always seems to be > a NOTE element saying "the request is processed in a background stream", even > if successful. > > Thanks, > Shawn >
I'm not saying what it's meant for, I'm just saying what it is. Currently, the only thing you can do to check for errors is override that method. I understand it's still somewhat limiting - it depends on your use case how well it can work. For example, I've know people that just want to stop the update process if a doc fails, and throw an exception. You can write code to do that by extending the class and overriding handleError. You can also collection the exceptions, count the fails, read and parse any error messages, etc. It doesn't help you with an ID or anything though - unless you get unluck/lucky and can parse it out of error messages (if it's even in them). It might be more useful if you could set the name of an id field for it to look for and perhaps also dump to that method. Their have been previous conversations about improving error reporting for this SolrServer, but no work has ever really gotten off the ground. There may be existing JIRA issues around this topic - certainly there are previous email threads. All and all though, please, make all the suggestions and JIRA issues you want. Javadoc improvements can be submitted as patches through JIRA as well. Also, the Wiki is open to anyone to update. - Mark Miller lucidimagination.com
