[
https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255602#comment-13255602
]
Shawn Heisey commented on SOLR-3284:
------------------------------------
If the Solr server goes down in between updates done with the concurrent
server, doing further updates will fail, but the calling code will not know
that. With the Commons or Http server, an exception is thrown that my code
catches.
I don't think that just overriding handleError is enough. If Solr goes down
but the machine is still up, you have immediate failure detection because the
connection will be refused. If the server goes away entirely, it could take a
couple of minutes to fail. You would have to provide methods to check that 1)
all background operations are complete and 2) they were error free.
I can no longer remember whether an exception is thrown when trying a commit
against a down machine with the concurrent server. IIRC it does throw one in
this instance. I definitely believe that it should. Perhaps the current
handleError code could update class-level members (with names like "boolean
updateErrored" and "SolrServerException updateException") that could be checked
and used by the commit method. If they are set, it would reset them and throw
an exception (fast-fail) without actually trying the commit. There should
probably be a constructor option and a set method to either activate this new
behavior or restore the original behavior.
When I first designed my code, I was relying on the exceptions thrown by the
commons server when doing the actual update, so it's too late by the time it
reaches the commit - it has already updated the position values. I now realize
that this is incorrect design, though I might never have figured it out without
my attempt to use the concurrent server. It's going to be a bit painful to
redesign my code to put off updating position values until after a successful
commit operation. It's something I do intend to do.
> StreamingUpdateSolrServer 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
> Reporter: Shawn Heisey
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
