lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Norskog (JIRA)" <>
Subject [jira] [Commented] (SOLR-3284) StreamingUpdateSolrServer swallows exceptions
Date Sat, 09 Jun 2012 06:41:23 GMT


Lance Norskog commented on SOLR-3284:

In the trunk it is now ConcurrentUpdateSolrServer, and it swallows errors all over the place.

I am a total fascist about fail-fast/fail-loud. A more obnoxious (fail-fast) design is:
* Any exception in a worker causes the main driver to kill all other workers.
* The default handler after this is a rollback.
* Add a flush() method to SolrServer. 
** CUSS uses this to report back to the main thread that everything blew up.
** Other server classes would do a socket flush and wait and drain out any error text.
* Use a finalize() method to complain that the user did not call flush(). 
** This is in all SolrServer classes- the same application code should do the same thing with
every SolrServer implementation.

We tell our customers to not use SUSS/CUSS because it does not do errors right. Partly this
causes problems because people tend to "design to success" (assume everything works) instead
of "design to failure" (assume everything breaks). When CUSS breaks, the production scripting
and staff do not notice. 

> StreamingUpdateSolrServer swallows exceptions
> ---------------------------------------------
>                 Key: SOLR-3284
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>    Affects Versions: 3.5, 4.0
>            Reporter: 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

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message