lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <>
Subject [jira] [Commented] (SOLR-3284) StreamingUpdateSolrServer swallows exceptions
Date Sun, 10 Jun 2012 20:13:43 GMT


Shawn Heisey commented on SOLR-3284:

Lance, if your idea (or your idea in combination with Mike's) can be implemented without a
ton of work, it should definitely replace my patch.  If it's a royal pain, my patch is there
as an interim solution and yours can be handled in another issue.

Is the following a good summary of your idea?  If so, I think your idea is better.  I think
it should be the default behavior for 4x and trunk.

A user of ConcurrentUpdateSolrServer would make update requests, then call a publicly exposed
flush(), either explicitly or implicitly by calling commit().  If the flush() fails due to
a background failure, all requests since the last successful flush() would be rolled back.
 If the user code is designed with this in mind, error handling is as good as HttpSolrServer.
 HSS (and probably ESS) would use flush() internally.  The user would be free to call flush()
themselves, but it would not be required.

I'm curious about how things would be handled with autoCommit or commitWithin.  Is rollback
possible when those are used?

> 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