Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-53761

Determine strategy to make the ServiceEntryPointCommon more asynchronous

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Performance
    • Labels:
    • Service Arch
    • Sharding 2021-02-22, Sharding 2021-03-08

      Background: this is the follow up to https://jira.mongodb.org/browse/SERVER-53505 trying to prevent the service entry point from blocking waiting for the tenant migration critical section blocker.

      The motivation to fix is is based on the anticipated outage when a tenant whose database is migrated to another replica set is sending too many clustered reads that are blocked by the migration critical section. The executor serving client reads will run out of free threads and/or create too many threads to accommodate the thread unavailability.

      Besides the blocker, we also have a prototype for asynchronous execution in runAsync, however it also returns a synchronous future, which will not unblock the thread when it's waiting.

      At the end, the service command invocation does something like `handleRequest().get()` like here. No matter how asynchronous the processing is, the `get()` is still blocking the thread.

      This ticket is to discuss what we can do about that.

            backlog-server-servicearch [DO NOT USE] Backlog - Service Architecture
            andrew.shuvalov@mongodb.com Andrew Shuvalov (Inactive)
            0 Vote for this issue
            8 Start watching this issue