[SERVER-30597] Best effort chunk metadata filtering for read concern 'available' Created: 10/Aug/17  Updated: 06/Dec/22  Resolved: 10/Nov/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt Dependency
has to be done after SERVER-30595 Do not use chunk metadata to filter r... Closed
Assigned Teams:
Sharding
Participants:

 Description   

For read concern 'available', use whatever chunk metadata is present to filter results, ignoring any shard version mismatch errors



 Comments   
Comment by Kaloian Manassiev [ 10/Nov/17 ]

Your observation is right and the purpose of the available read concern is to be used in degraded cluster mode. Because of this I think it makes no sense to implement this, so I am going to close it as Won't Fix.

Comment by Dianna Hohensee (Inactive) [ 10/Aug/17 ]

I wonder if this would annoy customers that try to use read concern 'available' against a secondary that just received data, but not yet the corresponding metadata. Then they wouldn't be able to read it. Though maybe SERVER-30226 would mostly resolve that: SERVER-30226 is a best effort concept as well, so we aren't guaranteeing that the recipient has the new metadata and the behavior still exists.

Generated at Thu Feb 08 04:24:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.