[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   
  • Clarify if this functionality is needed, and if so clarify if it should have spec for.
  • Address the temporary patch introduced in SingleServerReadBinding by
    CSHARP-3306
     


 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:

GridFSForwardOnlyDownloadStream
GridFSSeekableDownloadStream 

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:

Then, implementers retrieve all chunks with files_id equal to id, sorted in ascending order on “n”.

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.

Generated at Wed Feb 07 21:45:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.