lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jessica Cheng (JIRA)" <>
Subject [jira] [Commented] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
Date Fri, 13 Dec 2013 20:05:07 GMT


Jessica Cheng commented on SOLR-5477:

I agree that auto-retry is not the right thing to do.

However, a timeout can possibly happen on the Overseer to node admin requests (if these requests
have no timeouts, it might be dangerous because a connection can be sometimes be sunk and
the client will never find out--we've actually seen this happen on the apache httpclient through
solrj). What I'm getting at is that for the same reason that we're changing this client to
Overseer request to being async, maybe the Overseer to node admin request should be async

> Async execution of OverseerCollectionProcessor tasks
> ----------------------------------------------------
>                 Key: SOLR-5477
>                 URL:
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud
>            Reporter: Noble Paul
>            Assignee: Anshum Gupta
> 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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message