Closed
Bug 1188416
Opened 10 years ago
Closed 10 years ago
Use monotonic clocks for Telemetry subsessionLength
Categories
(Toolkit :: Telemetry, defect)
Toolkit
Telemetry
Tracking
()
People
(Reporter: gfritzsche, Assigned: gfritzsche)
References
Details
(Whiteboard: [unifiedTelemetry] [uplift4])
Attachments
(1 file, 1 obsolete file)
10.18 KB,
patch
|
gfritzsche
:
review+
ritu
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
We are seeing negative payload.info.subsessionLength values in the wild.
This may just be jumping/broken clocks and us not using monotonic clocks for this.
We need to fix not using monotonic clocks for that calculation.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → gfritzsche
Assignee | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•10 years ago
|
||
Attachment #8639964 -
Flags: review?(alessio.placitelli)
Comment 2•10 years ago
|
||
Comment on attachment 8639964 [details] [diff] [review]
Use monotonic clocks for Telemetry subsessionLength
Review of attachment 8639964 [details] [diff] [review]:
-----------------------------------------------------------------
::: toolkit/components/telemetry/tests/unit/head.js
@@ +247,5 @@
>
> return new Date(date);
> }
>
> +function fakeMonotonicNow(ms) {
Are we planning on using monotonic clocks somewhere else right now?
Is there any reason why this isn't simply:
let m = Cu.import("resource://gre/modules/TelemetrySession.jsm");
m.Policy.monotonicNow = () => ms;
return ms;
Attachment #8639964 -
Flags: review?(alessio.placitelli) → review+
Comment 3•10 years ago
|
||
Comment on attachment 8639964 [details] [diff] [review]
Use monotonic clocks for Telemetry subsessionLength
Review of attachment 8639964 [details] [diff] [review]:
-----------------------------------------------------------------
::: toolkit/components/telemetry/TelemetrySession.jsm
@@ +805,5 @@
> // The running no. of all subsessions for the whole profile life time
> _profileSubsessionCounter: 0,
> // Date of the last session split
> _subsessionStartDate: null,
> + // Start time of the current subsession per performance.now() for monotonically increasing
performance.now() ? Did you mean Policy.now()?
Comment 5•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Assignee | ||
Comment 6•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Attachment #8639964 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8641671 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Updated•10 years ago
|
status-firefox39:
wontfix → ---
status-firefox41:
--- → affected
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8641671 [details] [diff] [review]
Use monotonic clocks for Telemetry subsessionLength
Approval Request Comment
[Feature/regressing bug #]:
Telemetry Unification
[User impact if declined]:
This is a simple fix for how we count how long a subsession / fragment of a session is.
We relied on potentially unstable clocks, this makes us use monotonic clocks instead.
It is part of a mostly fixup & diagnostic uplift batch for 41: http://bit.ly/1LYhA16
[Describe test coverage new/current, TreeHerder]:
We have automated test-coverage, it baked on Nightly, we are monitoring it.
[Risks and why]:
Low-risk, we haven't seen anything crop up on Nightly here.
[String/UUID change made/needed]:
None.
Attachment #8641671 -
Flags: approval-mozilla-aurora?
Comment on attachment 8641671 [details] [diff] [review]
Use monotonic clocks for Telemetry subsessionLength
[Triage Comment]
Approved for uplift to Beta41. This patch has been in Nightly for a while so should be safe to uplift.
Attachment #8641671 -
Flags: approval-mozilla-aurora? → approval-mozilla-beta+
Assignee | ||
Comment 9•10 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•