[
https://issues.apache.org/jira/browse/SOLR-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890452#comment-17890452
]
Jason Gerlowski commented on SOLR-6122:
---------------------------------------
I agree with David - the thorough discussion here is awesome!
I like Approach 2 overall, but one question: if "cancel" is a task that goes
into collection-queue-work just like anything else, wouldn't that mean that
it's likely to get processed *after* the thing it's trying to cancel? Or put
differently - if a user queues a bunch of async backups and then decides to
cancel one of them, how often will the "cancel" be processed before the
backup-to-be-cancelled has already started?
(To be clear: my question above isn't rhetorical - I honestly don't know. I
know queued items aren't necessarily processed in strict order due to various
locking and parallelism mechanisms, but I'm hazy on those details. Hopefully
someone knows what the impact of that would be.)
Anyway, that concern aside - it sounds like most folks prefer Approach 2 over
Approach 1 for complexity reasons?
> API to cancel an already submitted/running Collections API call
> ---------------------------------------------------------------
>
> Key: SOLR-6122
> URL: https://issues.apache.org/jira/browse/SOLR-6122
> Project: Solr
> Issue Type: Wish
> Components: SolrCloud
> Reporter: Anshum Gupta
> Priority: Major
>
> Right now we can trigger a long running task with no way to cancel it
> cleanly.
> We should have an API that interrupts the already running/submitted
> collections API call.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
