https://issues.apache.org/jira/browse/SOLR-445
This JIRA reflects the slightly different case of wanting better reporting of *which* document failed in a multi-document packet, it doesn't specifically address SUSS. But it might serve to give you some ideas if you tackle this. On Tue, Mar 27, 2012 at 11:14 AM, Mark Miller <markrmil...@gmail.com> wrote: > > 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 > > > > > > > > > > >
