Skip to content

do not block ToC on in-collection operations by arc-ing collections#7999

Merged
generall merged 2 commits intodevfrom
arc-collection
Jan 27, 2026
Merged

do not block ToC on in-collection operations by arc-ing collections#7999
generall merged 2 commits intodevfrom
arc-collection

Conversation

@generall
Copy link
Member

@generall generall commented Jan 26, 2026

This PR attempts to address the following observed behavoir:

  • 1 collection exist in the cluster, this collection receives heavy traffic.
  • We create another collection nearby
  • Collection creation and traffic block each other.

Why it might happen?

When we perform any operation like search, upsert, snapshots ... we lock TableOfContent for read.
When we want to create new collection, we need to lock TableOfContent for writes.
Lock for write works like this:

  • it waits for all current operations to finish (this might be couple of seconds+)
  • it doesn't allow any new operations to preceed
  • queue of operations builds up
  • result == longer latency, maybe even timeout

(unconfirmed, but it might be, that queue of operations might also cause exhaustion of the threads)

This PR removes requirement to hold TableOfContent lock for collection ops, making critical section significantly smaller.
As a result: write doesn't wait for queue => operations don't have time to queue up.

Downside: we have a bit less strict guarantees about collection ownership during deletion of the collection, so we need to spinlock there.

@generall generall requested a review from timvisee January 26, 2026 23:37
coderabbitai[bot]

This comment was marked as resolved.

@qdrant qdrant deleted a comment from coderabbitai bot Jan 27, 2026
use std::sync::Arc;
use std::time::{Duration, Instant};

pub async fn try_unwrap_with_timeout_async<T>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only spin lock on:

  • collection deletion
  • collection creation, while collection already existed (unlikely)

No concerns there 👍


existing_collection.stop_gracefully().await;

let removed_collection_res = try_unwrap_with_timeout_async(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: concurrent collection creation calls are not a concern here. They are serialized by a 'creation' lock and consensus.

@qdrant qdrant deleted a comment from coderabbitai bot Jan 27, 2026
@generall generall merged commit 5a3793d into dev Jan 27, 2026
15 checks passed
@generall generall deleted the arc-collection branch January 27, 2026 13:26
IvanPleshkov pushed a commit that referenced this pull request Jan 27, 2026
…7999)

* do not block ToC on in-collection operations by arc-ing collections

* review suggestion fix
generall added a commit that referenced this pull request Feb 9, 2026
…7999)

* do not block ToC on in-collection operations by arc-ing collections

* review suggestion fix
@timvisee timvisee mentioned this pull request Feb 17, 2026
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants