[SERVER-20502] Cached chunk version is not updated on mongod when useClusterClientCursor=false Created: 18/Sep/15 Updated: 14/Apr/16 Resolved: 24/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Misha Tyulenev | Assignee: | Misha Tyulenev |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: | run this via resmoke or in mongo shell:
the test.user version on st.d0 (shard0) should be 2 but with useClusterClientCursor=false its 0 However, if the code after
is not executed the test.user version is 0 for both code paths. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Sharding A (10/09/15) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: |
| Description |
|
mongos with useClusterClientCursor=true and legacy show different behavior. |
| Comments |
| Comment by Misha Tyulenev [ 24/Sep/15 ] |
|
The old behavior is expected. No need to fix. |
| Comment by Randolph Tan [ 23/Sep/15 ] |
|
I don't think this is a bug, this is behavior works as expected for the setShardVersion protocol. I think what was happening before, is: Note that the shard never trusts the versions info from setShardVersion. So, unless the command has authoritative set to true, the shard will never check the config server to cross check. So, it looks like the new implementation behaves as if authoritative is set to true. Also note that in the old case, s2 didn't not need to send a setShardVersion with authoritative true to d0 after step#2 since it doesn't need to talk to it to serve the query. |
| Comment by David Storch [ 23/Sep/15 ] |
|
Are there any user-facing consequences of this on the 3.0 or 2.6 branch? If not, I propose closing this ticket as Won't Fix (or maybe Gone Away), since the code path containing the bug is going away soon in master. |