[
https://issues.apache.org/jira/browse/SOLR-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884755#comment-17884755
]
Yuntong Qu edited comment on SOLR-6122 at 9/26/24 1:53 PM:
-----------------------------------------------------------
I've looked into the flow for Collections API going through the route of
overseers more closely. Using Backup as an example.
{code:java}
>From any node:
Client -> CollectionsHandler.BACKUP_OP -> CreateCollectionBackup ->
CollectionsHandler.submitCollectionApiCommand -> put into ZK queue
Overseer
OverseerTaskProcessor.call() to process ZK queue -> OverseerTaskProcessor.run()
-> OverseerCollectionMessageHandler.processMessage().call() ->
OverseerTaskProcessor.Runner.run() -> BackupCmd.call() ->
BackupCmd.incrementalCopyIndexFiles() -> per slice send leader replica
sendShardRequest with BACKUPCORE_OP as CoreAdminOp
On replica leader Core
CoreAdminHandler.handleRequestBody() -> submitAsyncTask with BackupCoreOp ->
BackupCoreOp.execute() -> CreateCoreBackup.createBackup() -> create snapshot
{code}
It's definitely possible to "cancel" a collections api from Overseer (task
tracking queue), as long as we remove a task from ZK's
/overseer/collection-queue-work and Overseers's in memory runningTasks &
runningZKTasks. Overseer will not care the response from individual core's
response.
Still using Backup as example, while not impossible, it would be quite hard to
cancel ongoing backup from core level. With CoreAdminHandler, each individual
core have no notion of Overseer, and even though that there is
CoreAdminAsyncTracker which tracking ongoing core admin requests, removing
BackupOp will not stop core from still backing up to repository.
Does it make sense for certain collections api (ones without much side effect,
mainly backup), we can support high level cancel from Overseer?
was (Author: yuntong):
I've looked into the flow for Collections API going through the route of
overseers more closely. Using Backup as an example.
{code:java}
>From any node:
Client -> CollectionsHandler.BACKUP_OP -> CreateCollectionBackup ->
CollectionsHandler.submitCollectionApiCommand -> put into ZK queue
Overseer
OverseerTaskProcessor.call() to process ZK queue -> OverseerTaskProcessor.run()
-> OverseerCollectionMessageHandler.processMessage().call() ->
OverseerTaskProcessor.Runner.run() -> BackupCmd.call() ->
BackupCmd.incrementalCopyIndexFiles() -> per slice send leader replica
sendShardRequest with BACKUPCORE_OP as CoreAdminOp
On replica leader Core
CoreAdminHandler.handleRequestBody() -> submitAsyncTask with BackupCoreOp ->
BackupCoreOp.execute() -> CreateCoreBackup.createBackup() -> create snapshot
{code}
It's definitely possible to "cancel" a collections api from Overseer (task
tracking queue), as long as we remove a task from ZK's
/overseer/collection-queue-work and Overseers's in memory runningTasks &
runningZKTasks. Overseer will not care the response from individual core's
response.
Still using Backup as example, while not impossible, it would be quite hard to
cancel ongoing backup from core level. With CoreAdminHandler, each individual
core have no notion of Overseer, and even though that there is
CoreAdminAsyncTracker which tracking ongoing core admin requests, removing
BackupOp will not stop core from still backing up to repository.
Does it make sense for certain collections api (ones without much side effect,
mainly backup), we can support high level cancel from Overseer?
> 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
