[jira] [Commented] (SOLR-3284) StreamingUpdateSolrServer swallows exceptions

["Shawn Heisey (JIRA)" <ji...@apache.org>]

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

Shawn Heisey commented on SOLR-3284:
------------------------------------

I had an idea for tracking the first update that caused an error.  This is a little convoluted, so bear with me a little, and let me know what you think.

This first part is something that I think would be a good idea to add even if the rest is useless: The server object will have a field called requestNumber, an AtomicInteger, that will be incremented every time an UpdateRequest is used.  When an UpdateRequest is made and it does not already contain a parameter called concurrentUpdateId, the string representation of the current requestNumber will be inserted into the request as the value of that parameter.  Originally I had planned to have it always use the incrementing integer values, but there will be a lot of people may already have an existing ID value, and using that value would be MUCH easier.  The concurrentUpdateId parameter that gets used will be included in the dummy response, and it can also be used when Runner logs status messages from each update.

Now for the rest: One of the methods on the server object will set the error handling method that will get used.  One choice will be exactly the way it works now, including the ability to override the handleError method.  Another choice will be to raise a flag that can be checked manually using various get methods.  The remaining choice would be very similar to the patch already attached to this issue, except that the update ID of the update that caused the first internal exception will be in the message on the encapsulating exception.

I've got some of this written already.  It is pushing my java skill boundaries a little.

Even if the latter part is not implemented, if the first part goes in, the user could override a new HandleError(Exception,String) method to track the ID of every update that fails, not just the first.

                
> 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-ALPHA
>            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 skillset.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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