[SERVER-44978] Make ReadThroughCache support asynchronous loading Created: 06/Dec/19  Updated: 29/Oct/23  Resolved: 04/Mar/20

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

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 0
Labels: PM-1645-Milestone-2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-45798 Infrastructure for Caching OCSP respo... Closed
is depended on by SERVER-46154 Make ReadThroughCache be driven by a ... Closed
Duplicate
is duplicated by SERVER-46442 Decouple AuthorizationManager update ... Closed
Related
related to SERVER-46442 Decouple AuthorizationManager update ... Closed
is related to SERVER-45215 Reads from default RWC cache shouldn'... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-03-09
Participants:

 Description   

As part of this change the ReadThroughCache should be made to perform the loading asynchronously, on a separate thread rather than doing it inline on the thread of the caller to acquire.

The asynchronous implementation should add the following methods to the API:

  • Future<ValueHandle> acquireAsync(const Key& key)
  • ValueHandle acquire(OperationContext* opCtx, const Key& key)

If an invalidate is called for a key, which is being concurrently loaded, it is acceptable to interrupt the loading of the key if it is currently in progress, but the acquire should not fail.



 Comments   
Comment by Githook User [ 03/Mar/20 ]

Author:

{'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-44978 Make the ReadThroughCache lookup asynchronous
Branch: master
https://github.com/mongodb/mongo/commit/e8da98999ff4aa201b2805fbd4b379a9f0e807a7

Comment by Githook User [ 27/Feb/20 ]

Author:

{'username': 'kaloianm', 'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-44978 Move the "cache generation" to AuthorizationManagerImpl

The "cache generation" concept is something specific to the
Authorization Manager and doesn't fit with an asynchronous (non
totally-ordered cache). This change moves it out of the ReadThroughCache
and makes it an AuthorizationManager concept.
Branch: master
https://github.com/mongodb/mongo/commit/d3df81cac59e3dd216c60e87b74ac7c444343201

Comment by Githook User [ 26/Feb/20 ]

Author:

{'username': 'kaloianm', 'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-44978 Remove accidentally added usage of getGlobalServiceContext() from ReadWriteConcernDefaults
Branch: master
https://github.com/mongodb/mongo/commit/51eceb8afa6610b4ff0befb92ec6039173bab00f

Comment by Githook User [ 15/Feb/20 ]

Author:

{'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-44978 Thread-through ServiceContext and ThreadPool to ReadThroughCache

There are no functional changes to this CR, it just instantiates every
usage of ReadThroughCache with a ServiceContext and ThreadPool, which
will be used for making the acquire method asynchronous.
Branch: master
https://github.com/mongodb/mongo/commit/611979eb5cafba7bb5369a19948f82453f117c65

Comment by Githook User [ 15/Feb/20 ]

Author:

{'username': 'kaloianm', 'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com'}

Message: SERVER-44978 Make the ReadThroughCache perform loads on a separate thread
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/f2063ed063b8a5fffafed4776edf3b2ca1533fca

Comment by Kevin Pulo [ 17/Dec/19 ]

An additional issue is that if this is done, and the maxTimeMs of the CRUD ops coming in is too short for the (inline) lookup() to succeed, then the cache could be starved. (At the moment, the cache will be populated, and the user CRUD op will then timeout immediately on starting.) So it might also be necessary to make the lookup()s occur in a separate thread.

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