This patch enables generating a JSON file that mirrors the scalar definitions
in Scalars.yaml. On local developer builds, this file is loaded when Firefox
starts to register all the scalars. If some change was introduced in the
definition files, the new scalar will be dynamically added.
The JSON definition file will be regenerated every time an artifact build
is performed or the build faster command is invoked.
MozReview-Commit-ID: Do3WjE38aIK
This patch enables generating a JSON file that mirrors the scalar definitions
in Scalars.yaml. On local developer builds, this file is loaded when Firefox
starts to register all the scalars. If some change was introduced in the
definition files, the new scalar will be dynamically added.
The JSON definition file will be regenerated every time an artifact build
is performed or the build faster command is invoked.
MozReview-Commit-ID: Do3WjE38aIK
We're starting a shift towards talking about release/prerelease data instead of
base/extended collection. For now this is just a naming change.
At the same time, we can render these attributes read-only, which is nice.
MozReview-Commit-ID: IRuKpzLYW7i
We're starting a shift towards talking about release/prerelease data instead of
base/extended collection. For now this is just a naming change.
At the same time, we can render these attributes read-only, which is nice.
MozReview-Commit-ID: IRuKpzLYW7i
With the removal of the old addonHistograms, all histograms are now registered.
So removing registered(Keyed)Histograms should be straightforward?
Unfortunately not, as this was how we filtered data based on dataset
(opt-in/opt-out), so a little more fiddling was needed to get C++ to only
serialize dataset-appropriate data (instead of post-facto filtering it in JS).
MozReview-Commit-ID: HDplhmzmzJl
To cut down on complexity, we don't require specifying any expiry versions.
Given that these events will be recorded non-persistently from off-train add-ons, they can be expired by shipping new add-on releases.
We also start to use the new "record on release" terminology here instead of opt-in/opt-out, but are not changing the internal functionality yet.
Technically, this is implemented by keeping a separate registry for the dynamic event information.
Built-in & dynamic events are tracked with separate numeric ids, so introduce a common identifier for both, an EventKey.
For actual event storage, the events are treated the same as built-in events. They are simply bucketed into the 'dynamic' process storage.
This approach ends up duplicating code paths that use the event info, but keeps a single implementation for recording, storage & serialization.
TelemetrySession's getKeyedHistograms asks for each keyed histogram
individually. This is inefficient and doesn't work well with the storage
refactor.
So, plumb through a subsession keyed histogram snapshot API and convert
TelemetrySession over to using it.
MozReview-Commit-ID: Af9dTqw99UA
Previously we were doing bad string manipulation nonsense. Now when asked for
snapshots C++ can return a properly-formated Object tree.
MozReview-Commit-ID: HAvIbgzUvMU
When sending the shutdown ping we launched the pingsender executable via
PR_CreateProcessDetached() which on both Linux and MacOS X would fork()
gecko's main process and then exec() the pingsender executable. On MacOS X
this seemed to trigger a race with the mozalloc shutdown procedure within the
forked process. This patch changes the telemetry logic to use nsIProcess
instead which relies on posix_spawnp() to launch the new executable making it
immune to issues related to mozalloc's shutdown.
Since we don't need C++ code anymore to run the pingsender the runPingSender()
method is also moved to TelemtrySend.
MozReview-Commit-ID: C7fZw1ZpVBO
addonHistograms isn't being used and has started getting in the way.
So it goes.
Leave the "Addon Histograms" section in about:telemetry for 60 days.
Remove it in bug 1355882
MozReview-Commit-ID: 4lm7ONirofl
addonHistograms isn't being used and has started getting in the way.
So it goes.
Leave the "Addon Histograms" section in about:telemetry for 60 days.
Remove it in bug 1355882
MozReview-Commit-ID: 4lm7ONirofl
Currently we hand over a crash ping to the pingsender via a pipe; if the
pingsender fails to send the ping we rely on the CrashManager assembling and
sending one instead. Since the crashmanager is not aware of whether the ping
was sent or not this causes duplication on the server side. To solve this
problem we save the ping to disk instead, read it from the pingsender and
delete the file only if the ping was sent. In this scenario the CrashManager
will know that a ping was already sent and will not send a new one.
This patch removes all the code used to deal with pipes between the telemetry,
crashreporter and pingsender code and also tries to cut down the amount of
platform-specific code we have in this machinery.
MozReview-Commit-ID: ASm2jnDagCK
On content process shutdown we send a content process ping to ensure we have
up-to-date data from the content process before it goes away. Now we need to
also flush the batched telemetry accumulations to the parent so that it can be
present in the ping.
No attempt is made to synchronize access to IPCTimerFired. It is safe to
re-enter.
No attempt is made to cancel the timer as its firing is benign.
MozReview-Commit-ID: 1gjNH9IPhKf
