[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: |
|
||||||||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 2 years, 24 weeks ago | ||||||||
| Epic Link: | DOCSP-9747 | ||||||||
| Story Points: | 2 | ||||||||
| Description |
DescriptionDownstream Change Summary This changes adds the following two timestamp fields to the currentOp output:
Description of Linked TicketIn 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 changesImpact to Other DocsMVP (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: |
| Comment by Githook User [ 25/Aug/21 ] |
|
Author: {'name': 'ian fogelman', 'email': 'ian.fogelman@mongodb.com', 'username': 'ianf-mongodb'}Message: |
| 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 pipeline = \\{ "$currentOp" : {}}
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? |