[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
