[DOCS-13896] Investigate changes in SERVER-51074: VectorClock is not gossiped correctly on newly started sessions Created: 24/Sep/20  Updated: 13/Nov/23  Resolved: 25/Aug/21

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: 4.8.0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Ian Fogelman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File CurrentOpAgg.json    
Issue Links:
Documented
documents SERVER-51074 VectorClock is not gossiped correctly... Closed
Participants:
Days since reply: 2 years, 24 weeks ago
Epic Link: DOCSP-9747
Story Points: 2

 Description   

Description

Downstream Change Summary

This changes adds the following two timestamp fields to the currentOp output:

  • "command.$configTime"
  • "command.$topologyTime"

Description of Linked Ticket

In order to gossip the different components of the vector clock, we attach them to both commands requests and their replies before to send them over the wire. This is done by calling the VectorClock::gossipOut() function.

This function inspects the tags of the current session to decide which components of the vector clock will be gossiped. If no session is found the default tags (passed to the function) will be used for this decision.

Now the problem is that a session can exists but it can be still in the early kPending state, in such a case it won't have any of the other tags.

This case it is not considered by the VectorClock::gossipOut() function. In fact if a session in a pending state is found we always threat the communication as external and the the default tags (passed to the function) will be ignored.

This results in the VectorClock components not being gossiped on all the newly started sessions.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Githook User [ 25/Aug/21 ]

Author:

{'name': 'ian fogelman', 'email': 'ian.fogelman@mongodb.com', 'username': 'ianf-mongodb'}

Message: DOCS-13896 Added configTime and topologyTime with timestamp fields to Sharded cluster tab
Branch: v5.0
https://github.com/mongodb/docs/commit/64931392330a259e278f95c1edc93742f10d4a8f

Comment by Githook User [ 25/Aug/21 ]

Author:

{'name': 'ian fogelman', 'email': 'ian.fogelman@mongodb.com', 'username': 'ianf-mongodb'}

Message: DOCS-13896 Added configTime and topologyTime with timestamp fields to Sharded cluster tab
Branch: master
https://github.com/mongodb/docs/commit/a0456e8961f8605bc3ade53a1c87da74e82bfb28

Comment by Tommaso Tocci [ 02/Aug/21 ]

ian.fogelman those fields will be only present in $currentOp results of a sharded cluster. Are you sure you are sending the $currentOp aggregation to a sharded cluster rather than a resplica set / standalone mongod ?

Comment by Ian Fogelman [ 02/Aug/21 ]

Hi tommaso.tocci , I tried the aggregation pipeline version of currentOps, I am still not seeing the additional time stamps referenced. Here is my latest attempt, see attached CurrentOpAgg.json for output:

pipeline = \\{ "$currentOp" : {}}
limited_aggregation = admin.aggregate( pipeline )
print(dumps(limited_aggregation, indent=2))

 

The only timestamps I see are "currentOpTime".

Comment by Tommaso Tocci [ 28/Jul/21 ]

ian.fogelman I'm not sure how the currentOp helper is implemented in mongosh, so would you mind trying directly with the $currentOp aggregation stage?

Generated at Thu Feb 08 08:09:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.