[SERVER-27965] thread OperationContext* down through ClusterClientCursor's next() and kill() methods Created: 09/Feb/17 Updated: 05/Apr/17 Resolved: 09/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Sharding |
| Affects Version/s: | 3.5.2 |
| Fix Version/s: | 3.5.3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| 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: | Sharding 2017-02-13 | ||||||||
| Participants: | |||||||||
| Description |
|
This removes the need for the AsyncResultsMerger to store an OperationContext*, which it uses to schedule finds, getMore's, and killCursors on remote shards. This makes it easier to deal with the RouterStageMerge being split into two parts (sending the finds to establish cursors, and sending the getMore's to pull and merge results), where both parts need to access the OperationContext*. |
| Comments |
| Comment by Kaloian Manassiev [ 13/Feb/17 ] |
|
Just out of curiousity - does the ARM really need the OperationContext for any operation-related properties or just the ServiceContext so it can access the sharding instance objects? |
| Comment by Githook User [ 09/Feb/17 ] |
|
Author: {u'username': u'EshaMaharishi', u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}Message: |