[SERVER-10904] Possible for _master and _slaveConn to be pointing to different connections even with primary read pref Created: 25/Sep/13  Updated: 16/Apr/15  Resolved: 10/Feb/15

Status: Closed
Project: Core Server
Component/s: Internal Client, Sharding
Affects Version/s: 2.2.4, 2.4.12, 2.6.5
Fix Version/s: 2.6.8

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Randolph Tan
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-9788 mongos does not re-evaluate read pref... Closed
is duplicated by SERVER-10901 Using read preference causes stale ve... Closed
Related
is related to SERVER-17441 mongos crash right after "not master"... Closed
is related to SERVER-7612 explicit primary read pref does not ... Closed
Tested
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

There is a potential bug in DBClientReplicaSet that would cause _lastSlaveOkConn and _master to be different even if readPref was set to primary. This is plausible in theory since _lastSlaveOkConn and _master are simply shared pointers, so _master and _lastSlaveConn in theory can point to different instances. Currently, I can't find a way to make this happen, but it is plausible since whenever we clear the pointer on the _master, we don't do it on _lastSlaveConn and vice versa.

One observed behavior from a user is that connection used to send setShardVersion is different from the actual connection that sends the query, and thus goes into this loop where the shard rejects because the version is wrong and mongos retries with the right setShardVersion (but on the wrong connection) until it reaches the maximum retries.



 Comments   
Comment by Githook User [ 10/Feb/15 ]

Author:

{u'username': u'renctan', u'name': u'Randolph Tan', u'email': u'randolph@10gen.com'}

Message: SERVER-10904 Possible for _master and _slaveConn to be pointing to different connections
Branch: v2.6
https://github.com/mongodb/mongo/commit/224067d03b7631d4c984fe99cccda3a0d2f6874c

Comment by Alexander Komyagin [ 16/Dec/14 ]

Reopening as per my conversation with renctan. We agreed that it makes sense to at least put some invariants around the involved code - it should allow for further progress in the event of reoccurrence.

Comment by Randolph Tan [ 01/Aug/14 ]

Note: Only the changes for 2.7.x in SERVER-9788 makes this impossible. The fix for v2.6 does not fix this problem.

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