-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Internal Code
-
None
-
Service Arch
-
Fully Compatible
-
ALL
-
Service Arch 2023-02-06
-
58
-
None
-
None
-
None
-
None
-
None
-
None
-
None
The unit-tests for SessionWorkflow use a thread-pool to handle requests, implying that the command processing part runs on a separate thread than the one that initiates it:
Future<DbResponse> _handleRequest(OperationContext* opCtx, const Message& request) noexcept {
auto [p, f] = makePromiseFuture<DbResponse>();
ExecutorFuture<void>(_threadPool)
.then([this, opCtx, &request, p = std::move(p)]() mutable {
p.setWith([&] { return _processRequest(opCtx, request); });
})
.getAsync([](auto&&) {});
return std::move(f);
}
Since we are using ExecutorFuture here, the rest of the continuation shown below may run on a thread that doesn't have the Client attached:
...
auto fr = std::make_shared<Frame>(shared_from_this());
return _getNextWork()
.then([&, fr](auto work) {
fr->metrics.received();
invariant(!_work);
_work = std::move(work);
return _dispatchWork();
})
.then([&, fr](auto rsp) {
_acceptResponse(std::move(rsp));
fr->metrics.processed();
_sendResponse();
fr->metrics.sent(*session());
_yieldPointReached();
fr->metrics.yielded();
});
...
As part of running _acceptResponse, we detach and kill the opCtx that must happen on a thread than has the Client attached (through ClientStrand), but that may not be the case in unit-tests (for both dedicated and shared threading models).
- is caused by
-
SERVER-68875 Reflow the SessionWorkflow loop
-
- Closed
-
- related to
-
-
- Closed
-