[SERVER-28458] unit test the wall clock reset admin error Created: 23/Mar/17  Updated: 06/Dec/17  Resolved: 06/Jun/17

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

Type: Task Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Jack Mulrow
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-05-29, Sharding 2017-06-19
Participants:

 Description   

The scenarios:
1.

  • set wallclocks in the past more that 1 year (the value of maxAcceptableLogicalClockDrift)
  • a write should get through (no check for the past time) and establish a cluster time on the node to the time in the past
  • now every attempt to assign logical time to current should return an error (rate error) because (wallclock time - cluster time ) > maxAcceptableLogicalClockDrift
  • confirm that when the (wallclock time - cluster time ) <= maxAcceptableLogicalClockDrift it works , i.e. there are two options:


 Comments   
Comment by Githook User [ 06/Jun/17 ]

Author:

{u'username': u'jsmulrow', u'name': u'Jack Mulrow', u'email': u'jack.mulrow@mongodb.com'}

Message: SERVER-28458 Unit test wall clock reset admin errors
Branch: master
https://github.com/mongodb/mongo/commit/6b05afb44da679600b682e0ef3c7061eb7e3403c

Comment by Misha Tyulenev [ 01/Jun/17 ]

updated the ticket per discussion

Comment by Jack Mulrow [ 31/May/17 ]

Also, right now the rate limiter only compares newly received times to the wall clock (here) and only errors if the new time is ahead of the wall clock. So even if a server's (wall clock time - cluster time) > maxDrift, as long as the newly received time is not maxDrift seconds past the wall clock time, it will still pass the rate limiter and be accepted by the clock. Should we update this ticket, or change the rate limiter?

Comment by Jack Mulrow [ 31/May/17 ]

misha.tyulenev I noticed while looking at SERVER-28355, that you described the wall clock reset error there as the admin setting the clock more than 1 year in the future, but here as more than 1 year in the past. Which of these should I be testing?

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