[SERVER-49975] Use separate thread pools for CatalogCache and its loaders Created: 29/Jul/20  Updated: 29/Oct/23  Resolved: 30/Jul/20

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

Type: Bug Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Tommaso Tocci
Resolution: Fixed Votes: 0
Labels: PM-1645-Milestone-2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Problem/Incident
causes SERVER-50542 Catalog Cache is not cleaned on Shard... Closed
is caused by SERVER-49292 Futurify CatalogCacheLoader API Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2020-08-10
Participants:
Linked BF Score: 45

 Description   

Currently a single threadpool is shared among the CatalogCache and its loaders. The problem is that the ShardServerCatalogCacheLoader needs to join its tasks to ensure that all the task-related operation contexts are destroyed in order to proceed with its destruction. At the same time the same ThreadPool is used also by the CatalogCache that uses ThreadClient to access the operationContext in its async tasks. These tasks needs to be joined in order to be able to destroy the ServiceContext.
Since the same thread pool can be joined just once but two different components needs to join it, we can't actually use a common shared thread pool.

The solution is to use a different threadpool for the CatalogCache and its loaders respectively until we will have a better framework to share thread pools among several components.



 Comments   
Comment by Spencer Brody (Inactive) [ 03/Aug/20 ]

Ah yeah, that makes sense. ScopedTaskExecutor does not currently have that support, although I expect it to be added in PM-1809.

Comment by Kaloian Manassiev [ 03/Aug/20 ]

Thanks spencer, this looks like it would only help with the shutdown case (so it doesn't require the outer Executor to be shut down). However, it will not help with the limited number of outstanding tasks that we want to allow. Are there plans to make these ScopedTaskExecutors also support a max number of outstanding tasks?

Comment by Spencer Brody (Inactive) [ 03/Aug/20 ]

This has already been closed so maybe it's moot now, but FYI tommaso.tocci kaloian.manassiev in case you didn't know about it, we now have ScopedTaskExecutor which lets you define a sub-executor that can be shutdown and joined to clean up the tasks scheduled against it, but without actually shutting down the underlying executor/thread pool backing it. Not sure if it would have worked for this use case, but figured I'd mention it since it's a relatively new component and I'm not sure how many people are aware of it.

Comment by Githook User [ 30/Jul/20 ]

Author:

{'name': 'Tommaso Tocci', 'email': 'tommaso.tocci@mongodb.com', 'username': 'toto-dev'}

Message: SERVER-49975 Use separate thread pools for CatalogCache and its loaders
Branch: master
https://github.com/mongodb/mongo/commit/7408f50908d307567e1c4f4b3844e55ad6bd8e01

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