[SERVER-44708] Use lastCommittedOpTime in InvocationArgs as the clientsLastKnownCommittedOpTime in the next synthetic getMore request Created: 18/Nov/19  Updated: 06/Dec/22  Resolved: 17/Dec/19

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

Type: Task Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Participants:

 Description   
  • Set the lastKnownCommittedOpTime field in appendReplyMetadata if the command is a getMore on oplog with tailable exhaust cursor.
  • Use the lastKnownCommittedOpTime in ReplyBuilderInterface::nextInvocation (from the last response) as the clientsLastKnownCommittedOpTime for the next getMore command as if that’s from the client.


 Comments   
Comment by Lingzhi Deng [ 17/Dec/19 ]

We will store the lastKnownCommittedOpTime (used in awaitData) in ClientCursor instead of using ReplyBuilderInterface::setNextInvocation implemented in SERVER-44510 to avoid serializing/deserializing exhaust getMore requests. Closing as "Won't Fix".

Comment by Lingzhi Deng [ 12/Dec/19 ]

Given the implementation of SERVER-44510, this is likely a dup of SERVER-44707. As long as we set the nextInvocation to be a new getMore request with a new lastKnownCommittedOpTime, the next exhaust getMore will set the clientsLastKnownCommittedOpTime correctly.

Generated at Thu Feb 08 05:06:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.