[
https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352240#comment-14352240
]
Mark Miller commented on SOLR-7203:
-----------------------------------
I'm just not okay with introducing data loss :) It's kind of a big deal in the
hardening of SolrCloud. If that is fussy, sue me. Especially when it's an issue
that has already been fixed.
bq. I think that should be OK to go in?
I think it's fine to have as an option that defaults to false - for many users,
a simple retry is the option they will pick - but I'm going to add javadoc to
it that explains using it is not safe unless you can gaurantee your clients
won't fight each other.
Leaving it off by default will also ensure inter node communication doesn't use
it, which is important to avoid replica inconsistency (which is the same as
data loss).
> NoHttpResponseException handling in HttpSolrClient is wrong
> -----------------------------------------------------------
>
> Key: SOLR-7203
> URL: https://issues.apache.org/jira/browse/SOLR-7203
> Project: Solr
> Issue Type: Bug
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Attachments: SOLR-7203.patch, SOLR-7203.patch
>
>
> We've got logic in HttpSolrClient to catch NoHttpResponseException and retry.
> However, this logic appears to be in the wrong place - it's in the
> createMethod function, which doesn't actually execute any http requests at
> all. It ought to be in executeMethod.
> Fixing this might help sort out the persistent Jenkins failures as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]