[
https://issues.apache.org/jira/browse/SOLR-6595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699566#comment-16699566
]
Jason Gerlowski commented on SOLR-6595:
---------------------------------------
I've attached a patch here which ensures that any collection-api response with
a non-empty "failure" property also has its status set to 500. This has the
advantage of covering things more generically and save us from constantly
finding new cases where the status property (and HTTP status code) is
incorrect. (There's a few different JIRAs open at the moment for similar
issues with various collection APIs.).
Reviewers might notice that I change the status to 500 not by throwing a
SolrException as is common, but my introducing a field in SolrQueryResponse as
a "status-override". I didn't like deviating from the normal way of doing
things, and I don't love introducing yet-another way to set the API status, but
I had trouble finding a good way to flatten the often-nested structure of the
"failure" map into a message for a SolrException without losing tons of
information that could help the user out. If anyone sees a better way here,
I'd love some review/feedback.
This change triggers a few additional test failures- the API calls in these
tests have apparently been failing for some time before this change but we
never noticed since the response status obscured the problem. So this patch
includes fixes for a number of these tests. I'm still building confidence that
I've caught all of these cases, hoping to flush out more status-related test
failures through the week. If my runs stop finding issues by the end of the
week, I'll be looking to commit.
> Improve error response in case distributed collection cmd fails
> ---------------------------------------------------------------
>
> Key: SOLR-6595
> URL: https://issues.apache.org/jira/browse/SOLR-6595
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.10
> Environment: SolrCloud with Client SSL
> Reporter: Sindre Fiskaa
> Assignee: Jason Gerlowski
> Priority: Minor
> Attachments: SOLR-6595.patch
>
>
> Followed the description
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL and generated a
> self signed key pair. Configured a few solr-nodes and used the collection api
> to crate a new collection. -I get error message when specify the nodes with
> the createNodeSet param. When I don't use createNodeSet param the collection
> gets created without error on random nodes. Could this be a bug related to
> the createNodeSet param?- *Update: It failed due to what turned out to be
> invalid client certificate on the overseer, and returned the following
> response:*
> {code:xml}
> <response>
> <lst name="responseHeader"><int name="status">0</int><int
> name="QTime">185</int></lst>
> <lst name="failure">
> <str>org.apache.solr.client.solrj.SolrServerException:IOException occured
> when talking to server at: https://vt-searchln04:443/solr</str>
> </lst>
> </response>
> {code}
> *Update: Three problems:*
> # Status=0 when the cmd did not succeed (only ZK was updated, but cores not
> created due to failing to connect to shard nodes to talk to core admin API).
> # The error printed does not tell which action failed. Would be helpful to
> either get the msg from the original exception or at least some message
> saying "Failed to create core, see log on Overseer <node.name>
> # State of collection is not clean since it exists as far as ZK is concerned
> but cores not created. Thus retrying the CREATECOLLECTION cmd would fail.
> Should Overseer detect error in distributed cmds and rollback changes already
> made in ZK?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
