[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882621#comment-13882621
]
Shalin Shekhar Mangar commented on SOLR-5477:
---------------------------------------------
Thanks Anshum.
# Why is it called a taskQueue in CoreAdminHandler? There is no queueing
happening here.
# Why is the taskQueue defined as a Map<String, Map<String, TaskObject>>? It
can simply be a Map<String, TaskObject>. The task object itself can contain a
volatile status flag to indicate running/completed/failure.
# The CoreAdminHandler.addTask with limit=true just removes a random (first?)
entry if the limit is reached. It should remove the oldest entry instead.
# OverseerCollectionProcessor.requestStatus returns response with “success”
even if requestid is found in “running” or “failure” map
# The ‘migrate’ api doesn’t use async core admin requests
# In all places where synchronous calls have been replaced with
waitForAsyncCallsToComplete calls, we need to ensure that the correct response
messages are returned on failures. Right now, the waitForAsyncCallToComplete
method returns silently on detecting failure.
# Although there is a provision to clear the overseer status maps by passing
requestid=1, it is never actually called. When do you intend to call this api?
# I don’t understand why we need three different maps for
running/completed/failure for overseer collection processor. My comment #2
applies here too. We can store the status in the value bytes instead of keeping
three different maps and moving the key around. What do you think?
> Async execution of OverseerCollectionProcessor tasks
> ----------------------------------------------------
>
> Key: SOLR-5477
> URL: https://issues.apache.org/jira/browse/SOLR-5477
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Anshum Gupta
> Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch,
> SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
> SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
> SOLR-5477.patch, SOLR-5477.patch
>
>
> Typical collection admin commands are long running and it is very common to
> have the requests get timed out. It is more of a problem if the cluster is
> very large.Add an option to run these commands asynchronously
> add an extra param async=true for all collection commands
> the task is written to ZK and the caller is returned a task id.
> as separate collection admin command will be added to poll the status of the
> task
> command=status&id=7657668909
> if id is not passed all running async tasks should be listed
> A separate queue is created to store in-process tasks . After the tasks are
> completed the queue entry is removed. OverSeerColectionProcessor will perform
> these tasks in multiple threads
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
