[
https://issues.apache.org/jira/browse/SOLR-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765239#comment-16765239
]
Tomás Fernández Löbbe commented on SOLR-13231:
----------------------------------------------
Just to clarify how this PR is changing the response of the async calls. When a
sync CREATE is done to Solr the response looks more or less like:
{code:xml}
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">2263</int>
</lst>
<lst name="success">
<lst name="127.0.0.1:7574_solr">
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">1588</int>
</lst>
<str name="core">test4_shard3_replica_n4</str>
</lst>
<lst name="127.0.0.1:8983_solr">
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">1714</int>
</lst>
<str name="core">test4_shard1_replica_n1</str>
</lst>
...
{code}
With a "success" key with a value node_name-> response named list for each of
the internal requests done. If some response is a failure, there will be a
"failure" key instead of a "success".
For the async case, the response is similar in the sense that the response is
tracked inside "success" or "failure", however, the response tracked is not the
result of the operation, but the immediate response that Solr gives when the
async request is recorded. Then, the node that is orchestrating the creation,
waits for all the internal async requests and records them outside of the
"success" "failure" keys, with the request ID as keys. Like:
{code:xml}
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">2263</int>
</lst>
<lst name="success">
<lst name="127.0.0.1:7574_solr">
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">0</int>
</lst>
</lst>
<lst name="127.0.0.1:8983_solr">
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">0</int>
</lst>
</lst>
...
<lst name="foo4136271107568343">
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">0</int>
</lst>
<str name="STATUS">completed</str>
<str name="Response">TaskId: foo4136271107568343 webapp=null
path=/admin/cores
params={qt=/admin/cores&collection.configName=test2.AUTOCREATED&newCollection=true&collection=test2&version=2&replicaType=NRT&async=foo4136271107568343&coreNodeName=core_node5&name=test4_shard2_replica_n2&action=CREATE&numShards=3&shard=shard2&wt=javabin}
status=0 QTime=0</str>
</lst>
<lst name="foo4136271109701956">
...
{code}
The current PR is changing this so that the async response is also tracked
inside "success" or "failure", also using the request ID as key and the
response as value. This is what a user would get back when they call
REQUESTSTATUS in the async ID they used to create the collection. So it is an
incompatible change as it is right now, so we either try to get this into 8.0,
we add some workaround for back compatibility or implement the fix in some
other way (shouldn't be difficult to inspect all the request IDs used to verify
the success/failure of a subrequest). I do think this the current approach is
better, if what we want to respond is the list of the request issued in the
corresponding (success/failure) map
> CREATE collection request doesn't fail or cleanup when the request fails
> ------------------------------------------------------------------------
>
> Key: SOLR-13231
> URL: https://issues.apache.org/jira/browse/SOLR-13231
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Tomás Fernández Löbbe
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a CREATE collection command is issued with an async ID, the request is
> marked as "completed" regardless of the output of the create. Also related,
> the ClusterState is not cleaned up in the same way as a in the sync request
> case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
