[
https://issues.apache.org/jira/browse/SOLR-6595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16702292#comment-16702292
]
Jason Gerlowski commented on SOLR-6595:
---------------------------------------
Thinking aloud here, and I guess also soliciting feedback.
The current patch sets 500 as the value for the "status' property, as well as
the HTTP status code on the response. The expectation in most other places
seems to be that the "status" property matches the HTTP status code. So this
seems like the technically correct thing to do from an API perspective.
There's is a downside to this though- SolrJ converts non-200 responses into
exceptions. So while the failure information is still in the response, SolrJ
users can't get at it. (This isn't strictly true...SolrJ tries its best to
come up with a good exception message by looking for properties like "error"
and "failure". But that's a pale substitute to giving users access to the
response itself if they want it).
It'd be cool if SolrJ users could access the original response in exceptional
cases. Maybe we should attach the parsed NamedList to RemoteSolrExceptions
that get thrown by SolrJ. That seems like a separate JIRA, but wanted to raise
it here since it bears on these response changes indirectly.
> 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]
