On 1/17/2013 12:38 PM, Chris Hostetter wrote:
: You're not only giving up the ability to monitor things, you're also giving up : the ability to detect errors. All exceptions that get thrown by the internals : of ConcurrentUpdateSolrServer are swallowed, your code will never know they : happened. The client log (slf4j with whatever binding & config you chose) may : have such errors logged, but they are completely undetectable by the code. This isn't the first time i've seen someone make this claim, but i really don't understand it -- ConcurrentUpdateSolrServer has a handleError() method that gets called when an error happens during the async processing. By default it just logs the exception, if you want to do something more interesting with it in your code, just subclass ConcurrentUpdateSolrServer and override that method -- that's the entire point of that method. The bigger issue is wether your client cod could reasonable do anything if/when that method is called -- because it's all async, you probably can't do much more then log/report it in your own custom way instead of just using org.slf4j.Logger.
I have my update process (using HttpSolrServer) encapsulated in a method that has several parts -- deletes, reinserts, a specific kind of partial reindex, and inserting new content. It ends with a commit(). Any exceptions that happen down inside this method are either rethrown or propagate. When the method is called, update position information is only updated if it returns without throwing an exception.
For my use case, it is enough to know that an error happened, exactly where it happened is not critical unless the problem turns out to be in the data - a scenario that has not happened so far. All failures so far have been due to the server or Solr being down.
I understand that many people would want to know which update failed. I hope to come up with a way to make this possible with CUSS out of the box.
Do you have an example of how to override handleError that would make error detection easy? IMHO, either that information should be easily accessible to someone who's looking at the javadoc for CUSS, or the class should provide an out of the box way to detect errors.
I will work on this problem, not just complain about the current state. Thanks, Shawn
