[CSHARP-3556] Reconsider server pinning in GridFS Created: 08/Apr/21 Updated: 31/Mar/22 |
|
| Status: | Backlog |
| Project: | C# Driver |
| Component/s: | GridFS |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Boris Dogadov | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | FY22Q3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
| Comments |
| Comment by Robert Stam [ 09/Apr/21 ] | ||
|
Looking more closely at the C# driver code I see that we have two kinds of download streams:
The first does in fact use a cursor. The second reads chunks one at a time.
| ||
| Comment by Jeffrey Yemin [ 09/Apr/21 ] | ||
|
I only see this in the spec:
| ||
| Comment by Robert Stam [ 09/Apr/21 ] | ||
|
I think the reason we don't use a cursor is that we model the GridFS download as a .NET `Stream` and we need to support skipping to an arbitrary location of the GridFS file. | ||
| Comment by Robert Stam [ 09/Apr/21 ] | ||
|
Doesn't the spec say to not use a cursor and to read one chunk at a time? I can't remember why GridFS downloads were supposed to be done that way, but it might have had something to do with not keeping resources tied up at the server. Other than that... I see no reason not to use a cursor. | ||
| Comment by Jeffrey Yemin [ 09/Apr/21 ] | ||
|
Interesting. I looked at the Java driver and it uses a cursor to iterate the chunks, which implicitly ties you to a single secondary. Does the C# driver do something different? | ||
| Comment by Robert Stam [ 09/Apr/21 ] | ||
|
Just want to note the reason we currently pin when downloading a GridFS file from a secondary, it is to prevent failures when some secondaries are lagging. If a download starts successfully against an up-to-date secondary it could fail if reads for subsequent chunks happen to be routed to a lagging secondary that doesn't have those chunks yet. The GridFS spec does not address this scenario. Pinning to a secondary to avoid failures only works when connected directly to a replica set. When connecting through mongos we have not control over which secondary gets selected when reading a chunk. An alternative fallback mechanism might be to fall back to the primary when a secondary does not yet have the needed chunk. Or we could just remove the pinning and say any failures due to lagging secondaries are not our concern. |