[
https://issues.apache.org/jira/browse/SOLR-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036598#comment-16036598
]
Varun Thacker commented on SOLR-8256:
-------------------------------------
Hi Dat,
This is how I understand async's mechanism:
It starts from the CollectionsHandler :
Here in the {{handleResponse}} there is two code paths: One for async and
without async.
For async we write a znode and send back the response to the user and ask it to
poll.
For not async we wait for a znode to be written back to and then send back the
response.
With the patch , since CreateShardCmd is no longer passing the async param to
the underlying add-replica call what will happen is that it becomes blocking
internally . That means if an add replica call took longer ( create core ) then
the request will timeout and you won't get back the response.
When you pass the async param to the add replica call which in turn passes it
to the CoreAdminHandler then it deals with it in an async manner ( in
CoreAdminHandler#handleRequestBody ) . So we should basically make sure that
the async param is always sent to
{{OverseerCollectionMessageHandler#sendShardRequest}} if there is one.
i'm not sure how we test async working correctly today. Someone else could
chime in here
> Set legacyCloud=false as default
> --------------------------------
>
> Key: SOLR-8256
> URL: https://issues.apache.org/jira/browse/SOLR-8256
> Project: Solr
> Issue Type: Improvement
> Reporter: Mark Miller
> Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch
>
>
> We don't have the old back compat concerns anymore. It's time to remove this
> mostly unknown setting and start defaulting to this behavior that starts us
> down the path of zk=truth.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
