On 2/12/2017 10:51 PM, Lasitha Wattaladeniya wrote: > Thanks for the reply. But even if I add a single document, the response > doesn't reflect the correct response status. From the given solr console > ui, it shows status 400 for the bad requests (when I try to index document > with no fields <doc></doc>). But when I do the same using solrj, response > is 0 eventhough the console prints it as a bad request with status 400.
The concurrent client swallows all indexing exceptions. This is how it is designed. In fact, it's potentially even worse than you might expect -- the client not only always returns a success for updates sent, it returns immediately, often before any updates are sent to the server. The updates are sent in the background. If another request type is sent, like a commit, then the client will wait for all queued updates to be sent before it sends that request and returns. If an error is encountered during an explicit commit, I believe that the client *is* notified about that, but I have not tested this. If you want multi-threaded indexing *and* error detection, you're going to need to handle the multiple threads in your own program, using the Http or Cloud client object instead. The Concurrent object is good for initial bulk indexing, but not for the kind of indexing where you want to be informed about errors. I'm told that if you override the "handleError" method, you might be able to make it work how you want, but I was unable to figure out how to modify that method to achieve that result. I filed an issue and even came up with an idea for a fix, but nobody was excited about it. Because of the design of the client, it wasn't possible to guarantee that no further indexing had occurred after the first error encountered. https://issues.apache.org/jira/browse/SOLR-3284 Thanks, Shawn
