[SERVER-33701] Change streams can send getMores without logical session ids Created: 06/Mar/18  Updated: 06/Dec/22  Resolved: 06/Apr/18

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

Type: Bug Priority: Major - P3
Reporter: Charlie Swanson Assignee: Backlog - Query Team (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-34204 Tailable cursor fails on getMore agai... Closed
Assigned Teams:
Query
Operating System: ALL
Participants:

 Description   

Running a change stream against a mongos will set up one or more tailable cursors on the shards, then continuously poll those cursors until there is an unconsumed result. This polling continues to happen in the background even between the client's getMores. As a result, the AsyncResultsMerger can schedule a request with a null operation context here. If this happens, the getMore will not include the logical session id, or possibly other information that is stored on the OperationContext.

Because the OperationContext is not required to be non-null within scheduleRemoteCommand, there may be other scenarios in which we do not include the logical session id or other metadata.



 Comments   
Comment by Asya Kamsky [ 06/Mar/18 ]

I'll need to figure out if we're moving in a direction where all operations will always start in a session or not...

Comment by Charlie Swanson [ 06/Mar/18 ]

tess.avitabile I'm not confident any tests will start failing, but I think we certainly want to support change streams against sharded clusters inside a session. I think (but I'm not sure) that's how we recommend using a change stream, and how drivers will do it.

cc asya

Comment by Tess Avitabile (Inactive) [ 06/Mar/18 ]

This means that change streams on sharded clusters in sessions will not work after SERVER-33367. If we don't do this, we will need to create a work-around (e.g. only check for matching session IDs if the getMore or originating command had a txnNumber, since that is all the validation that is required for transactions).

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