[jira] [Commented] (SOLR-3284) ConcurrentUpdateSolrClient swallows exceptions

["Shawn Heisey (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15728806#comment-15728806 ] 

Shawn Heisey commented on SOLR-3284:
------------------------------------

I really didn't expect to see any activity on this.  I mostly opened it so we'd have the ability to tell people that the limitations of the Concurrent client have not escaped our attention.

Thinking about the notion of it being possible for changes beyond the first error to have been indexed, I have to compare this to the way that I handle errors in my current SolrJ index maintenance program (using HttpSolrClient).

A full update cycle consists of individual deletes, a possible mass delete query, reinserts, a possible reindex of a portion of the index, and then new docs (inserts).  If any part of that fails, I assume the entire cycle has failed.  I don't try to figure out exactly where a failure happened -- all actions for a failed cycle are repeated on the next loop.

This works despite the imprecise error detection, because I have a properly configured and properly used uniqueKey field.  Also, I am not using the atomic update feature.  The increment, decrement, and add/remove functionality (for multiple values) in Atomic Update would be incompatible with failure scenarios where you can't be sure about which updates succeeded and which failed.


> ConcurrentUpdateSolrClient swallows exceptions
> ----------------------------------------------
>
>                 Key: SOLR-3284
>                 URL: https://issues.apache.org/jira/browse/SOLR-3284
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>    Affects Versions: 3.5, 4.0-ALPHA
>            Reporter: Shawn Heisey
>            Assignee: Shawn Heisey
>         Attachments: SOLR-3284.patch
>
>
> StreamingUpdateSolrServer eats exceptions thrown by lower level code, such as HttpClient, when doing adds.  It may happen with other methods, though I know that query and deleteByQuery will throw exceptions.  I believe that this is a result of the queue/Runner design.  That's what makes SUSS perform better, but it means you sacrifice the ability to programmatically determine that there was a problem with your update.  All errors are logged via slf4j, but that's not terribly helpful except with determining what went wrong after the fact.
> When using CommonsHttpSolrServer, I've been able to rely on getting an exception thrown by pretty much any error, letting me use try/catch to detect problems.
> There's probably enough dependent code out there that it would not be a good idea to change the design of SUSS, unless there were alternate constructors or additional methods available to configure new/old behavior.  Fixing this is probably not trivial, so it's probably a better idea to come up with a new server object based on CHSS.  This is outside my current skillset.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org