[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
