[SERVER-36964] Prevent secondaries in SessionsCollectionRS from attempting to set up the sessions collection. Created: 31/Aug/18  Updated: 08/Jan/24  Resolved: 13/Oct/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.6.7, 4.0.2, 4.1.2
Fix Version/s: 3.6.9, 4.0.4, 4.1.5

Type: Bug Priority: Major - P3
Reporter: Blake Oler Assignee: Blake Oler
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Duplicate
is duplicated by SERVER-36954 server keeps trying to create an inde... Closed
is duplicated by SERVER-40441 Arbiter nodes log error messages when... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Sprint: Sharding 2018-09-24, Sharding 2018-10-22
Participants:

 Description   

Problem

In the LogicalSessionCache on replica sets, both primaries and secondaries attempt to create the sessions collection or its indexes. The secondary should only check that the collection and indexes exist before performing operations. The primary will be responsible for both creating the collection and ensuring that the indexes exist.

Proposed Fix

  1. In SessionsCollection::setupSessionsCollection, have secondaries instead check for collection and index existence. If either doesn't exist, return an error status. Otherwise, continue.


 Comments   
Comment by Githook User [ 23/Oct/18 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-36964 Prevent secondaries in SessionsCollectionRS from attempting to set up the sessions collection.

(cherry picked from commit c388d2db35d576862ebf42758686df340bc0bb9f)
Branch: v3.6
https://github.com/mongodb/mongo/commit/3bf02defe2e16b9de339fca4717d3d65ee779eac

Comment by Githook User [ 22/Oct/18 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-36964 Prevent secondaries in SessionsCollectionRS from attempting to set up the sessions collection.

(cherry picked from commit 6894b72f134534c3739a66ed9eee11e265b9c1e1)
Branch: v4.0
https://github.com/mongodb/mongo/commit/c388d2db35d576862ebf42758686df340bc0bb9f

Comment by Githook User [ 13/Oct/18 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-36964 Prevent secondaries in SessionsCollectionRS from attempting to set up the sessions collection.
Branch: master
https://github.com/mongodb/mongo/commit/6894b72f134534c3739a66ed9eee11e265b9c1e1

Comment by Misha Tyulenev [ 01/Oct/18 ]

how do you check for the index? Also if an index exists does it imply the collection also exists?

Comment by Misha Tyulenev [ 06/Sep/18 ]

The approach lgtm

Comment by Blake Oler [ 06/Sep/18 ]

mira.carey@mongodb.com misha.tyulenev I updated the proposed fix in the description. Let me know if you ack

Comment by Blake Oler [ 05/Sep/18 ]

misha.tyulenev updated the approach. It tweaks the way the inheritance structure works, so want to get your lgtm on this before building it out.

Comment by Misha Tyulenev [ 31/Aug/18 ]

blake.oler all operation should return same error: e.g. Status (ErrorCode::LockBusy) and the caller can then deal with it.

Comment by Blake Oler [ 31/Aug/18 ]

misha.tyulenev you mentioned in discussion about this issue in SERVER-36923 that an unsuccessful mutex lock should return instead of blocking. Should this apply to all operations (refresh, remove, setup, et al.) or do you prefer the behavior be configurable based on the operation to be done?

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