lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sami Siren (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3284) StreamingUpdateSolrServer swallows exceptions
Date Tue, 17 Apr 2012 09:43:18 GMT

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

Sami Siren commented on SOLR-3284:
----------------------------------

What are the operations/error situations where you are not seeing an Exception when you expect
one?

By default the ConcurrentUpdateSolrServer (StreamingUpdateSolrServer) just logs the exceptions
from updates but you can override this functionality:

{code}
    SolrServer server = new ConcurrentUpdateSolrServer("http://127.0.0.1:8983/solr", 1, 1){
      public void handleError(Throwable ex) {
        //do something with the Throwable here
        System.out.println("Something wrong!" + ex.getMessage());
      }
    };
    
    server.add(new SolrInputDocument());

{code}

The current exception reporting is pretty limited and it is impossible to see which operation
triggered the exception but such improvements should be done in separate issues.
                
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message