[SERVER-35890] Make Authorization user cache a general purpose lifetime manager Created: 28/Jun/18  Updated: 29/Oct/23  Resolved: 01/Aug/18

Status: Closed
Project: Core Server
Component/s: Internal Code, Security
Affects Version/s: None
Fix Version/s: 4.1.2

Type: Improvement Priority: Major - P3
Reporter: Spencer Jackson Assignee: Jonathan Reams
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Problem/Incident
Related
is related to SERVER-31552 Authorization User Cache should be ab... Closed
Backwards Compatibility: Fully Compatible
Sprint: Platforms 2018-07-02, Platforms 2018-07-16, Platforms 2018-07-30, Platforms 2018-08-13
Participants:
Linked BF Score: 18

 Description   

The AuthorizationManager maintains a pool of User* objects. Callers which need to access to a particular User* will fetch it from the pool and bump a ref-count. Periodically, the AuthorizationManager may discover that an update has occurred which pertains to a particular User*. When this occurs, it will mark the User* as invalid by settingan Atomic variable on the object, and remove it from the pool. Future callers will no longer be able to acquire the invalid User* from the pool, and will have to create a new instance from disk. Past callers will eventually check and discover that their User* is invalid, discard it, and fetch a new instance from the pool. Once the User*'s refcount reaches 0, it will be freed.

 

This pool allows concurrent, eventually consistent, access to point in time copies of read-only data. Once a User* is checked out, no locks are required to access it. Once a User* is invalidated, its consumers will eventually figure out they should stop using it. The pool maintains a generation counter, which can be advertised by config servers. A mongos operating off a different generation count than its config server will know that its cache is inconsistent and should be purged.

 

This pattern would be useful to manage the lifetimes of other types of objects in a cluster. We should extract the pool from the AuthorizationManager, and templatize it to operate off generic types.

Additionally, the pool should not track and hand out bare pointers. Instead it should expose managed RAII pointers. Callers should not be required to perform manual ref-count manipulation.



 Comments   
Comment by Githook User [ 01/Aug/18 ]

Author:

{'username': 'jbreams', 'name': 'Jonathan Reams', 'email': 'jbreams@mongodb.com'}

Message: SERVER-35890 Fix fassert codes
Branch: master
https://github.com/mongodb/mongo/commit/0713f5f35754a5c443450cef960f5d4c5845a725

Comment by Githook User [ 01/Aug/18 ]

Author:

{'name': 'Jonathan Reams', 'email': 'jbreams@mongodb.com', 'username': 'jbreams'}

Message: SERVER-35890 refactor User cache into InvalidatingLRUCache and UserHandle
Branch: master
https://github.com/mongodb/mongo/commit/2c504892ae516f56dc127dee1146baf894a5fc59

Comment by Benjamin Caimano (Inactive) [ 31/Jul/18 ]

Reverted over BF-10099

Comment by Githook User [ 31/Jul/18 ]

Author:

{'name': 'Ben Caimano', 'email': 'ben.caimano@10gen.com'}

Message: Revert "SERVER-35890 refactor User cache into InvalidatingLRUCache and UserHandle"

This reverts commit 78dec3622268ad27bb855eda4c6a4ed345412fd9.
Branch: master
https://github.com/mongodb/mongo/commit/6711ab3bbc02ca98da1af2fe115f07e37bb076e4

Comment by Githook User [ 31/Jul/18 ]

Author:

{'name': 'Jonathan Reams', 'email': 'jbreams@mongodb.com', 'username': 'jbreams'}

Message: SERVER-35890 refactor User cache into InvalidatingLRUCache and UserHandle
Branch: master
https://github.com/mongodb/mongo/commit/78dec3622268ad27bb855eda4c6a4ed345412fd9

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