[SERVER-20758] Delete legacy mongos cursor manager and legacy query path Created: 05/Oct/15 Updated: 17/Nov/15 Resolved: 11/Nov/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.0-rc3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | QuInt C (11/23/15) | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The legacy mongos cursor manager (the "CursorCache") and the corresponding legacy query path are currently not used by default, though they currently remain available to the user (via --setParameter useClusterClientCursor=false). We are aiming to leave the code for this path in the server for 1-3 release candidates for a couple of reasons:
If no bugs are discovered, this code should be deleted before the stable release is shipped. The tasks for this ticket are as follows:
|
| Comments |
| Comment by Githook User [ 11/Nov/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |
| Comment by Githook User [ 11/Nov/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |
| Comment by Githook User [ 11/Nov/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: Also removes the useClusterClientCursor |
| Comment by Githook User [ 12/Oct/15 ] |
|
Author: {u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}Message: |
| Comment by J Rassi [ 05/Oct/15 ] |
|
Per discussion, the new path is using SyncClusterConnection under the hood for the initial find, which takes care of the case where some config servers are unavailable, and we are intentionally not handling the "needs catalog swap" error from the config servers ( |
| Comment by Kaloian Manassiev [ 05/Oct/15 ] |
|
What happens for queries against queries against the config or admin databases on clusters backed by 'legacy' (sync cluster connection) config servers? Those cannot use the new find command logic, because they have different retry logic. |