[SERVER-45577] Submit range deletion tasks using fixed executor Created: 14/Jan/20  Updated: 29/Oct/23  Resolved: 12/Feb/20

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-02-10, Sharding 2020-02-24
Participants:
Linked BF Score: 0

 Description   

Updated Description

The task to submit range deletions was scheduled using an arbitrary sharding executor to avoid deadlocks in unit tests that involve metadata refreshes. If the unit tests use mocks for the refreshes instead, the deletions can be scheduled on the fixed sharding executor while still avoiding deadlocks.

Original Description

The task to submit range deletions may need to force a refresh if the filtering metadata is unknown, so we should add a way for the task to wait for the refresh without blocking in a thread pool thread.



 Comments   
Comment by Githook User [ 11/Feb/20 ]

Author:

{'username': 'jsmulrow', 'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com'}

Message: SERVER-45577 Submit range deletion tasks on fixed executor
Branch: master
https://github.com/mongodb/mongo/commit/dc1270c064fa71529d33395bd031c5965fba2a0b

Comment by Esha Maharishi (Inactive) [ 10/Feb/20 ]

jack.mulrow I didn't totally follow what you're saying about the CatalogCacheLoaderMock, but if you have an idea, go for it.

 

Edit: Oh I see, using the CatalogCacheLoaderMock instead of the real CatalogCache would allow us to avoid the deadlock.

Comment by Jack Mulrow [ 07/Feb/20 ]

I tried using a real ThreadPool and wasn't able to make it work, but I noticed we already have a CatalogCacheLoaderMock class, which I think I can use to get around this issue instead, since it's the calls through the CatalogCache to ShardRemote::_runExhaustiveCursorCommand() that use the fixed executor and are causing the unit tests to hang when we also use the fixed executor to schedule the deletion. I'll give this approach a shot next week.

Comment by Esha Maharishi (Inactive) [ 03/Feb/20 ]

Hmm, that's true, I forgot about the arbitrary TaskExecutor TODO.

I don't think we should leave it as the arbitrary executor, since unlike the fixed executor, which uses a ThreadPool with unlimited size, the arbitrary executors use a NetworkInterfaceThreadPool, which I believe uses a single thread.

I checked if it's possible to make unit tests use a fixed executor with a larger thread pool size, but it doesn't seem easy to do this, since unit tests use an executor with a ThreadPoolMock, which seems to have an explicit single worker thread.

Maybe we can change the unit tests to use a fixed executor with a real ThreadPool, like initial_syncer_test.cpp does? I'm not sure if this would work, but could you give this a try and see if it's possible?

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