[
https://issues.apache.org/jira/browse/SOLR-18605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133846#comment-18133846
]
David Smiley commented on SOLR-18605:
-------------------------------------
Implementation: A possible approach is to generate an internal async ID and
simply auto-delete it at completion (say if it contains a flag to do so and/or
if the ID has a certain prefix). I'm *not* saying it _should_ work this way,
I'm merely offering a possible workable implementation approach that might be a
bit easy /to do.
> async=true should mean "fire and forget" (async without tracking)
> -----------------------------------------------------------------
>
> Key: SOLR-18605
> URL: https://issues.apache.org/jira/browse/SOLR-18605
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: David Smiley
> Priority: Major
>
> 🤖 Some clients want to run an admin command asynchronously without ever
> polling for its completion status. Examples: a cron job that triggers a
> backup, or a shard split that will complete (or fail) eventually. Not every
> client can do anything meaningful by polling. Today such a client must still
> supply a unique {{async}} request ID per call, and Solr stores a status for
> it that nobody will read; it lingers until cleaned up via {{DELETESTATUS}}.
> h3. Proposal
> Reserve {{async=true}} as a special value meaning "fire and forget":
> * The command executes asynchronously and the response returns immediately,
> as with any async request.
> * No async ID is claimed in ZooKeeper, so repeated calls never collide.
> * No result is stored, so there's nothing to clean up via {{DELETESTATUS}}.
> * The response omits {{requestid}}.
> {{async=false}} is treated as synchronous (i.e. as if {{async}} were absent).
> h3. Scope
> * Collections API, both Overseer and distributed modes
> ({{CollectionsHandler}}, {{DistributedCollectionConfigSetCommandRunner}}).
> * CoreAdmin async ({{CoreAdminHandler}}).
> * V2 APIs whose {{async}} request-body field flows through the same code
> paths.
> * SolrJ: optionally a no-arg variant on {{CollectionAdminRequest}} (e.g.
> {{processAsync()}} without an ID); could be a follow-up.
> * Ref guide: async sections of the Collections API and CoreAdmin pages.
> h3. Back-compat
> Today {{true}} is treated as an ordinary request ID: the first call claims
> it, and later calls fail with "Task with the same requestid already exists"
> until it's deleted. Anyone relying on the literal ID {{true}} would lose the
> ability to track it. That's unlikely, but worth a note in major-changes.
> h3. Testing
> Integration test: issue two {{async=true}} Collections API requests
> back-to-back; both succeed, the work completes (e.g. wait for collection
> state), and no request status is stored. Similar case for CoreAdmin.
> 🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
