[SERVER-8475] Small clock skew with NTP can give strange locked values on queries Created: 08/Feb/13  Updated: 25/Oct/13  Resolved: 25/Oct/13

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

Type: Bug Priority: Minor - P4
Reporter: David Hows Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

Tue Feb  5 04:24:26 [conn12345] command XXXXX.$cmd command: { findandmodify: "XXXXX", query: { _id: 123456 }, sort: { _id: 1 }, new: 1, remove: 0, upsert: 0, update: { $pull: { XXXXX: "GUID" } } } ntoreturn:1 keyUpdates:0 locks(micros) w:18446743918042 reslen:336 1271310163ms

The write lock value on that query appears to be 7 months.

Checking their NTPD logs showed that ntpd was winding back 140 milliseconds (by default its max ntp will do is 200ms)

This looks like it could cause problems in our query execution - as it becomes possible for a query to appear to have started after it ended.

Checking the Timer (util/timer.h) class shows that if we have a clock windback around when we call now() we could potentially generate a negative number. The values we use to capture these numbers are unsigned long long's which would cause problems in the event of a negative number.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 25/Oct/13 ]

Yup, thanks, dup of SERVER-4740

Comment by Asya Kamsky [ 24/Oct/13 ]

dup of SERVER-4740

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