[SERVER-64174] Ensure timers/sessions added to `BatonASIO` are cancelable Created: 03/Mar/22  Updated: 12/Dec/23  Resolved: 12/Dec/23

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: 6.0 Desired
Fix Version/s: 7.3.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Amirsaman Memaripour Assignee: Ryan Berryhill
Resolution: Fixed Votes: 0
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Issue split
split from SERVER-61192 Session cancellation should interrupt... Closed
Assigned Teams:
Service Arch
Backwards Compatibility: Fully Compatible
Sprint: Service Arch 2022-03-21, Service Arch 2023-11-13, Service Arch 2023-11-27, Service Arch 2023-12-11, Service Arch 2023-12-25
Participants:

 Description   

Adding a timer/session to a BatonASIO while it is polling translates to a task scheduled on the baton. The task will add the timer/session to the baton once it's done polling.

This behavior has an unwanted consequence: if we attempt to cancel the timer/session before the scheduled task is processed, we cannot find the timer/session on the baton. The current implementation of BatonASIO misinterprets that for an already canceled timer/session and simply returns from cancelTimer and cancelSession.

The expected outcome for this ticket is to fix this behavior so that timers/sessions added to BatonASIO while it is polling are also cancelable.

There are two unit-tests the exercise the conditions described in this ticket:



 Comments   
Comment by Githook User [ 12/Dec/23 ]

Author:

{'name': 'Ryan Berryhill', 'email': 'ryan.berryhill@mongodb.com', 'username': 'ryanberryhill'}

Message: SERVER-64174 Ensure sessions and timers added to AsioNetworkingBaton are cancelable

GitOrigin-RevId: fada100f38da46dddb387053579d3fa76ded466e
Branch: master
https://github.com/mongodb/mongo/commit/88b3c34c75c7baa943841992c1a3e95764381624

Comment by Matt Diener (Inactive) [ 27/Apr/23 ]

https://github.com/10gen/mongo/pull/12404 mitigates this by polling on the reactor and only using the baton as the worker for copying bytes and running aync callbacks. Should that not perform well, I presume more reactor threads can be added to the ARS task executor, working on the same io_context.

Generated at Thu Feb 08 05:59:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.