[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876232#comment-13876232
]
Shalin Shekhar Mangar commented on SOLR-5477:
---------------------------------------------
Some comments on the last patch:
# Why have two different sets of parameter names; 'requeststatus' with 'id' for
collection handler and 'reqstatus' with 'requestid' for
OverseerCollectionProcessor? Let's make it the same. Maybe just call it
'status' with a request_id?
# In CollectionHandler.handleSplitShardAction, the following can throw NPE if
ASYNC is not present. Use Boolean.parseBoolean instead:
{code}
if (req.getParams().get(ASYNC).equals("true")) {
props.put(ASYNC, "true");
}
{code}
# Shouldn't the CollectionHandler should add support for async in all commands
and not just create collection and split?
# CollectionHandler.handleResponse should actually check for non-null value of
"async" Just checking if the key exists is not enough.
# I guess the client creating/managing the id part is not implemented in the
last patch.
# In DistributedQueue.createData -- there is debug logging that should be
marked with nocommit and removed
# DistributedQueue.getNumericId is an unused method
# DistributedQueue.containsValue creates a new String from byte[] with the
default charset. Similar issues with String.getBytes. Run ant
check-forbidden-apis from inside the solr folder for a full list.
# The completed queue and the failure queue are actually for
OverseerCollectionProcessor so they should be named appropriately i.e.
/overseer/collection-queue-completed and /overseer/collection-queue-failed
# Why are items being put in the completedQueue in Overseer? The async and
status support is only for collection commands not overseer commands.
# The OverseerCollectionProcessor.processMessage catches Throwables with this
patch. It should be changed back to catching Exception only.
# Processing OverseerCollectionProcessor tasks in multiple threads is a key
requirement because these tasks can be long running. Just making them
asynchronous is not enough. This hasn't been addressed in this patch yet.
> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
