[SERVER-28143] Create and destroy Client for tasks started through launchAsync Created: 28/Feb/17  Updated: 12/Dec/23

Status: Backlog
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Cluster Scalability
Resolution: Unresolved Votes: 0
Labels: AdiZ
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Cluster Scalability
Participants:

 Description   

To use launchAsync correctly, it should always be used like so,

{
    .....
    auto future = launchAsync([this] {
        ON_BLOCK_EXIT([&] { Client::destroy(); });
        Client::initThreadIfNotAlready("Test");
        auto txn = cc().makeOperationContext();
 
        ..... // use txn
    }
    .....
    future.timed_get(kFutureTimeout);
}

The instances of launchAsync without the above, is incorrect usage (we have a good bit of that, too). Therefore, we should move the above into launchAsync, so it isn't repeated everywhere and it's always used correctly.

This is the definition of launchAsync, found in network_test_env.h

    /**
     * Helper method for launching an asynchronous task in a way that will guarantees that the
     * task will finish even if the task depends on network traffic via the mock network and there's
     * an exception that prevents the main test thread from scheduling responses to the network
     * operations.  It does this by returning a FutureHandle that wraps std::future and cancels
     * all pending network operations in its destructor.
     * Must be defined in the header because of its use of templates.
     */
    template <typename Lambda>
    FutureHandle<typename std::result_of<Lambda()>::type> launchAsync(Lambda&& func) const {
        auto future = async(stdx::launch::async, std::forward<Lambda>(func));
        return NetworkTestEnv::FutureHandle<typename std::result_of<Lambda()>::type>{
            std::move(future), _executor, _mockNetwork};
    }

A solution would be to wrap the 'func' lambda within another lambda, with the redundant code, and then return that.


Generated at Thu Feb 08 04:17:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.